perm filename S55.JAM[S,DOC] blob
sn#002729 filedate 1972-07-19 generic text, type T, neo UTF8
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
STANFORD ARTIFICIAL INTELLIGENCE LABORATORY - SEPTEMBER 25, 1970
OPERATING NOTE NUMBER 55.2
STANFORD A-I PROJECT MONITOR MANUAL
CHAPTER II - USER PROGRAMMING
by Andy Moorer
This is the second chapter of the STANFORD A-I MONITOR MANUAL,
describing machine language programming of the PDP-10 under the
time-sharing monitor currently in use at Stanford. User input-output
operations are described in detail and descriptions of all UUOs
(monitor call instructions) are given. The advanced user may be
interested only in the index, part II.F, while the beginner will
certainly be interested in the introduction sections, parts II.A,
Ii.B, and II.C.
You can get the latest corrections to this chapter by using the
UPDATE program. The entire manual is on a file called
"S55.JAM[S,DOC]".
This work was supported by the Advanced Research Projects Agency of
the Department of Defense under Contract SD-183.
1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
KEYWORD INDEX TO CHAPTER II . . .
II.A INTRODUCTION TO MACHINE-LANGUAGE PROGRAMMING
introduction and disclaimer
definition of core memory
instruction format
symbolic instructions
indexing
indirect addressing
II.B INTRODUCTION TO INPUT-OUTPUT PROGRAMMING
II.C DATA REPRESENTATIONS - SYSTEM STORAGE
II.C.1 DATA MODES - IO STATUS BITS
Status Bits.
Legal Data Modes.
II.C.2 DUMP MODE COMMAND LISTS
II.C.3 BUFFER RINGS
II.C.4 JOB DATA AREA
II.C.5 TEXT REPRESENTATIONS
ASCII (7-bit).
ASCIZ
ASCID
SIXBIT
RADIX50
II.C.6 SYSTEM PARAMETER REPRESENTATIONS
File Names.
Device Names.
Project-Programmer Names.
Dates.
II.D UN-USED OPERATION CODES (UUOs)
II.D.1 UUOs TO INITIALIZE DEVICES
INIT
OPEN
II.D.2 UUOs TO SET UP BUFFER RINGS
INBUF
OUTBUF
UINBF
UOUTBF
II.D.3 UUOs TO MANIPULATE FILES
LOOKUP
ENTER
RENAME
II.D.4 UUOs TO DO DATA TRANSFERS
IN
INPUT
OUT
OUTPUT
II.D.5 UUOs TO TERMINATE IO
CLOSE
RELEAS
2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.6 SPECIAL TELETYPE UUOs
TTYUUO
TTYIOS
CTLV
PTYUUO
II.D.7 SPECIAL MAGNETIC TAPE UUO
MTAPE
II.D.8 SPECIAL III DISPLAY UUOs
DPYCLR
PPIOT
UPGIOT
PGIOT
UPGMVM
UPGMVE
II.D.9 SPECIAL LIBRASCOPE UUOs
UFBCLR
UFBGET
UFBGIV
FBREAD
FBWRT
II.D.10 SPECIAL DECTAPE UUO
UTPCLR
II.D.11 RANDOM ACCESS PROVISIONS
USETI
USETO
UGETF
II.D.12 CHECKING IO STATUS
GETSTS
STATZ
STATO
SETSTS
II.D.13 UUOs TO GET INFORMATION
DATE
TIMER
MSTIME
RUNTIME
PJOB
GETPPN
SWITCH
DEVCHR
PEEK
PNAME
JBTSTS
CHNSTS
BUFLEN
NAMEIN
II.D.14 SPACEWAR MODE
SPCWAR UUO
SPCWAR CALL
3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
SPCWGO
II.D.15 SECOND PROTECTION-RELOCATION REGISTER
Introduction
Definition of high segment
REMAP
SETUWP
CORE2
ATTSEG
DETSEG
SEGNUM
SEGSIZ
LINKUP
POINTS
SETPRO
SETNM2
SEGNAM
II.D.16 USER INTERRUPT SYSTEM
INTENB
INTORM
INTACM
INTENS
INTIIP
INTIRQ
DISMIS
INTGEN
USKIP
UWAIT
DEBREAK
IWAIT
IENBW
INTMSK
IMSKST
IMSKCL
CLKINT
INTUUO
INTJEN
II.D.17 WHAT HAVE YOU . . .
EIOTM
LIOTM
CORE
WAIT
EXIT
LOGIN
LOGOUT
SLEEP
MAIL
APRENB
SWAP
SETNAM
4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
REASSIGN
RESET
RUNMSK
SLEVEL
CALL
CALLI
II.D.18 FURTHER EXAMPLES
II.E DEVICE-DEPENDENT PECULIARITIES
II.E.1 LINE PRINTER
II.E.2 PAPER TAPE PUNCH
II.E.3 DECTAPES
II.E.4 DISK
II.E.5 TV CAMERAS
II.E.6 AD-DA CONVERTER
II.E.7 MAGNETIC TAPES
II.E.8 USER DISK PACK
II.F ALPHABETICAL INDEX
5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.A INTRODUCTION TO MACHINE-LANGUAGE PROGRAMMING
If you have never programmed a computer in machine language
before, you are probably in big trouble. This chapter may ease the
pain somewhat, but it will still be very confusing for a while. I
suggest you start out by getting a copy of the DDT manual after you
read this section and try writing small programs with it first rather
than leaping directly into the higher level assembly languages.
If you do not understand binary or octal notation and if you do
not know what a bit is, please read DEC's "Introduction to
Programming" or the equivalent before you attempt to brave this
section.
To provide some amount of motivation for reading further, I shall
start by attacking a simple problem: given two numbers in memory, add
them together and place the sum in memory. This trivial program
requires I explain many of the basic concepts of computers. We shall
start with memory:
The computer has two kinds of memory: core memory and bulk
memory. Bulk memory means storage on separate devices like the disk
and will be discussed in detail later. Core memory is much faster
and very fundemental to the operation of the machine.
Core memory is divided into compartments called "words". Each
word has a unique name, called its "address", which is a number
between 0 and 131071 on our current machine at Stanford. Each word
is 36 binary bits long and is capable of holding a decimal number
between -34359738368 and +34359738367.
To write the example program, I would first have to tell you the
addresses of the words in memory that contained the numbers I wished
to be added together, and I would have to tell you the address of the
word where the sum is to go. When we do this example, I will tell
you all these things.
The computer has many operations it is capable of performing.
When we write a program, all we are doing is writing down a list of
the basic operations we wish to do. To run the program, we encode
these operations as numbers and put them in memory, remembering the
addresses of the words where they are. Programs are generally in
consecutive memory locations. The computer, unless told otherwise,
will execute instructions from consecutive memory locations. We may
then tell the computer the address in memory of the beginning of our
program and begin its execution there. When the program is
completed, we must tell the computer to stop by placing a HALT
instruction at the end of our program.
Each 36-bit word in memory may contain a piece of data or the
code for an instruction. The computer can not analize a word and
tell what it is. It is for this reason that you must tell the
computer where your program is.
When a word is used as an instruction, rather than as a word of
data, the computer expects it to be in a very special format. It
expects the operation code in the first nine bits and the address of
II.A-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
the data word, if any, that this operation uses in the last 18 bits.
The bits within a word are numbered, zero to 35, left to right, high
order to low order. For example, the number 5 is represented by bit
33 a one, bit 35 a one, and all other bits zero. To phrase the
instruction format this way, we say the operation code is in bits 0
through 8 and the data address is in bits 18 through 35.
At this point, you may be asking yourself what is in bits 9
through 17. This will be explained later.
If I say an ADD instruction has an operation code of octal 270,
this means that this operation is specified by bits 1, 3, 4, and 5
being one, and bits 0, 2, 6, 7, and 8 being zero.
The first 16 words of memory on this computer are what are called
"fast registers". Whereas most other words in memory may be accessed
within 2 microseconds, any of these fast registers may be accessed in
less than .5 microseconds. It is partly for this reason, and mainly
for historical reasons, that these registers are called
"accumulators". Notice that since they are locations 0 through 15
(17 in octal) it only takes 4 bits to specify an accumulator. This
is very handy, because it takes up to 18 bits to specify an arbitrary
memory location, and an instruction only has 36 bits to play around
with.
If we use 9 bits for the operation code (hereafter referred to as
the "op code") and 18 bits for the address part, we have 9 bits left
over. This is enough to specify two 4-bit accumulators and one bit
left over. This is, in fact, exactly how they are used on the
PDP-10. Bits 9 through 12 contain an accumulator address.
Now that you know all this, I can tell you exactly how the ADD
instruction, op code 270, works. It fetches the word in memory whose
address is found in bits 18 through 35 of the instruction, adds it to
the number in the accumulator whose address is in bits 9 through 12
of the instruction, and places the sum back in the accumulator.
Voila!
Notice that the sum replaces one of the addends. This is
generally the way things work. The result of an arithmetic operation
generally replaces one of the arguements.
Some definitions now: Bits 0-8 are called the "instruction field"
of an instruction word and contain the op code. Bits 9-12 are called
the "accumulator field" and contain the address of an accumulator.
Bits 18-35 are called the "address field" and contain the address of
a word in memory.
II.A-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
***************************************************************
* OP CODE * AC FIELD * I * INDEX FIELD * ADDRESS FIELD *
***************************************************************
0 8 9 12 13 14 17 18 35
ILLUSTRATION OF FORMAT OF PDP-10 MACHINE-LANGUAGE INSTRUCTIONS
Notice that if bits 18-35 of an instruction contained a number
less than 16, it would refer to an accumulator. As a matter of fact,
you could cause an accumulator to be added to itself by having the
accumulator field and the address field contain the same number.
This is legal and is often a reasonable way to do things.
To do an addition, one of the addends must already be in an
accumulator. If the addends are all in memory to start with, we must
move one of them into an accumulator before the addition can be done.
We do this, naturally enough, with the MOVE instruction, op code 200.
This instruction takes the word in the address contained in the
address field and puts it in the accumulator whose address is in the
accumulator field.
There is also a way to move accumulators back into memory. This
is done with the MOVEM instruction, op code 202.
Now, I believe we have enough instructions to write our program.
Let us say that the addends are in locations 1000 and 1001, and we
wish to add them together and place the sum in location 1002. We may
do this by first doing a MOVE from location 1000 to an accumulator,
doing an ADD from 1001 to that same accumulator, and doing a MOVEM of
that accumulator to location 1002. Now that we know what to do, the
only remaining problem is representing our program.
In memory, a MOVE from location 1000 to an accumulator, say
accumulator 2 for example, would look like the octal number
200100001000. If you separated this out and decoded it, you would
find 200 in the instruction field, 2 in the accumulator field, and
1000 in the address field. This is all fine for the computer, which
can do that decoding very quickly, but is awkward for a person to
read. For this reason, we write programs in a more esthetic form and
use another program, called FAIL, to translate our representation
into numbers like 20010000100. We would write this instruction as
MOVE 2,1000 and let FAIL encode it. In this representation, we write
down the instruction mnemonic first, the accumulator field followed
by a comma, and the address field. If the accumulator field and the
comma are left out, accumulator 0 is used.
So, we may write our little program as follows:
MOVE 2,1000
ADD 2,1001
MOVEM 2,1002
The only things we have left out here are the addresses of the
locations where these instructions are to go and the HALT at the end
II.A-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
of our program. The fact that we used accumulator 2 is arbitrary.
Any accumulator would have worked.
So much for the basics. Now on to greater things! Bits 14
through 17 of the instruction contain another accumulator address.
The contents of this accumulator are added to the number in the
address field to produce a new address. If bits 14-17 are zero, as
in our program above, then the address field itself is uses as the
actual address. Bits 14-17 are called the "index field". The
accumulator specified by the number in the index field is called the
"index register". The contents of the index register are called the
"index". Only accumulators 1 to 15 may be used as index registers
because 0 is used to mean no indexing is to take place. Remember
that it is not the index field itself that is added to the address,
but the contents of the accumulator (index register) whose address is
in the index field.
The reason indexing exists is to help process sets of ordered
data. For example, if we had a store with 200 customers and we
wanted to add up each customer's account, we could put the account
balances in 200 consecutive locations and go through them in order by
executing the same program with a different number in the index
register each time, the index being the customer number.
We represent indexing by enclosing the index number in
parentheses and placing it after the address. For an example, let us
consider this instruction:
MOVE 2,1000(3)
If accumulator 3 contained the number 1, then this instruction would
move the contents of location 1001 into accumulator 2. To restate,
this instruction moves into accumulator 2 the word whose address is
1000 plus the contents of accumulator 3.
There is one bit that remains unexplained. Bit 13 of the
instruction is called the "indirect bit". If this bit is on, it
means that the number you get from adding the address field to the
index is not the final address (the final address is called the
"effective address") but is instead the "indirect address". This
causes the machine to pick up bits 13-35 of the word whose address is
the sum of the address field and the index and start calculating the
effective address all over again. It takes this new address field
and adds it to the new index, if any, and if the new bit 13 is a one,
bits 13-35 of this word are fetched and the effective address
calculation is started all over again for the third time. One can
easily see that this process could be endless if one of the addresses
along the line pointed back to the original instruction. This is
called an indirect addressing loop and should be avoided.
Indirect addressing is specified by placing an at sign (@) in
front of the address field as follows:
MOVE 2,@1000
II.A-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
This means that we don't put the contents of location 1000 into
accumulator 2, but instead use it as another address.
Now I have explained the entire instruction word format and all
about effective address calculation. If should be pointed out that
the effective address calculation produces an 18 bit number when
indexing is used. That is, bits 0-17 of the index are ignored and
only bits 18-35 are added to the address field. This is not true of
indirect addressing, because it has to pick up the entire word to
start computing the effective address all over again.
At this point, it would be wise to pick up a copy of the DEC
"PDP-10 System Reference Manual" and read pages 1-1 to 2-68. This
will tell everything I have said here plus much more. It explains
each instruction and there are quite a few. you needn't read section
2.12 because unless you are a systems programmer, you will not be
able to use those instructions anyway. You should probably read the
FAIL manual also, SAILON number 26.1, to find out all the other
interesting features is has.
There are several concepts one should be familiar with before one
goes too far with learning about the machine. If you are a class-A
beginner, you might skip over these next few paragraphs, but please
return to read them before you get too far along.
The first concept I would like to introduce in this discussion is
that of Absolute versus Relocatable. Our computer operates in what
is usually called a "Multi-programming" environment. This means that
several people's jobs are in core memory at the same time. Since
memory is numbered from 0 to the maximum, the beginning of each job's
core image is not at location zero. But each program is written as
if the first location of the program is zero, so there is a conflict
here, for not everyone can have their core image located at location
zero. To resolve this problem, there is a set of boundary registers,
called the protection-relocation registers, which, when a job is
running, make the first location of that job appear as if it were
location zero, and makes any references out of the job's core image
illegal. The address of the first word of a job is called the job's
"relocation constant". The number of words in a job's core image is
called the job's "protection constant". When the monitor is in
control, the protection-relocation register is disabled so the
monitor has free access to all of memory. When a user is started up,
the protection-relocation register is set to make it look as if he
were the only job in memory and as if his first location were
location zero and his last location were the last location in memory.
A job may request to have his core image expanded or contracted to
give himself more or less room in which to operate. The
protection-relocation scheme is completely invisible to the user, and
I mention it only to resolve any question you may have about how so
many people may use the machine at once and all have their own
private location zero.
II.A-5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
You may have noticed that I have referred to the
protection-relocation register in the above paragraph as both
singular and plural. This is because although there is only one
hardware register, it is capable of holding two different relocation
constants and two different protections. Normally, only one of these
is active at a time. If a user so wishes, he may activate the other
one by means of the UUOs listed in section II.D.15.
The true addresses in core are called "absolute" or "exec"
addresses. The addresses within a user's job which starts at zero
are called "relative" or "user" addresses. Often if you get an error
printout, the program counter at the time of the error will be
printed also. If the location in memory where the error occured was
in the user's core image, it will be expressed as "AT USER xxx". If
the error is outside the user's core area and inside the monitor, it
will be expressed as "AT EXEC xxx".
OK, now you know the difference between relative addresses and
absolute addresses. To complete the confusion, I shall tell you
about relocatable assembly versus absolute assembly. Here, the term
"absolute" means something different, for we are talking about two
ways of approaching programming within a user's core image. What I
am trying to get at is this: There are two types of relocation and
absolute addressing. One is a hardware register which divides up
main core memory into absolute addresses and user address. The type
I wish to discuss now is a software relocation that is used to load
several separate subroutines (or programs) into a single user core
image.
When you write a bunch of subroutines, you do not specify to the
assembler (unless you do explicitly with, for example, a LOC
statement to FAIL) the address of the first location of each
subroutine. Instead, you just ignore the problem. The assembler
will then translate your program so that all addresses are relative,
or displacements, from the first word of the routine. This is called
a "relocatable" assembly, because the exact origin of the routine is
not defined by the assembler, and the addresses are all relative to
the first word of the program. This is why the binary output files
that assemblers and compilers produce are called .REL files, because
they are relative to the origin of the subroutine rather than
absolutely defined.
This leaves the process of defining these origins and relocating
the addresses to a program called the Loader. When you load many
subroutines into a single core image, the Loader defines their
origin, one by one, and does what are called "fixups" to the
addresses to change them from relative addresses to absolute
addresses within the core image. The loader is capable of making any
address calculation the assembler itself is, in that when the various
addresses become explicitly defined, it is capable of multiplying,
dividing, and a number of other operations to get the address you
requested. The Loader does software relocation of programs, the
protection-relocation register does hardware relocation of jobs.
II.A-6
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
Most of this is invisible to you and will only be important for
special purpose work. You can get a core map from the Loader which
tells the origin of all the programs it has loaded for you. For more
about this and other interesting topics, be sure to tune in to
section I.B.4.f.4 for Batman meets the Loader!
II.A-7
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.B INTRODUCTION TO INPUT-OUTPUT PROGRAMMING
The basic objective of input-output (hereafter referred to as IO)
is to transfer data from the computer's main memory to or from a
device. There are many devices on the computer. There are tapes,
disks, teletypes, displays and a host of others. Each device is
quite different from each other and requires entirely different
strategies. Some devices, like the disk, are common to all users and
a scheme must exist for keeping users out of each other's hair. This
is the task of the monitor. The monitor accepts requests from user
programs for IO transfers, and delivers the request to the particular
part of the monitor that is in charge of the requested device, called
the device service routine. It is up to the device service routine
to engage the proper interlocks and make sure the device is operated
properly.
To transmit data between users and so many unique devices, a
request for a transfer must be standardized so as to look about the
same regardless of what device it is going to. This is the
motivation for the design of the monitor's IO scheme. It is fairly
general and solves all the above mentioned problems.
The system has subdivided the operations into three main
catagories: initializations, data transfers, releasing. To do a
transfer, you must first initialize the device, you must tell the
system you wish to use this device. If the device is not available
to you at this time, an error return will be taken. If the device is
available, you may do data transfers to or from it. When you are
finished with the data transfers, you must release the device so
other users may use it.
This scheme is called system IO. There are other simpler forms
of IO for special devices, like the teletype, but they are special
cases and are dealt with in detail in subsequent sections.
All communication between a program and the monitor is done by
illegal instruction traps to the monitor. Since the op codes from
040 to 077 are not used by any instruction, we use them to
communicate with the monitor. These are the Un-Used Operation codes,
hereafter referred to as UUOs. A UUO is an instruction which is
executed by the system instead of by the computer. Often, the words
immediately after the UUO are used as arguements of the UUO to the
monitor. You should read the individual writeups in section II.D
before you actually attempt to use a UUO. I shall attempt to
describe the usage of some of the IO UUOs in a simple manner here.
There are two UUOs to initialize a device. These are the INIT
UUO (section II.D.1) and the OPEN UUO. These two UUOs are
functionally identical but merely have different formats. I shall
discuss the INIT UUO.
A program may be doing IO to as many as sixteen devices at once.
To keep straight which transfer goes with which device, we use what
is called a "channel number". When you INIT a device, you give its
name and a channel number from 0 to 17 octal. Every operation that
II.B-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
refers to that device after the INIT is identified by its channel
number. If you INIT a device on channel 1, all your data transfer
instructions must refer to channel 1. If you refer to a channel
other than 1, the monitor will assume you mean some other device.
So, you only refer to a device by its name once, when you INIT the
device. Thereafter, you refer to it by its channel number. This is
a number you chose yourself.
Now it is time to talk about data modes. If you look in section
II.C.1 you will find a description of all the strange modes you may
do data transfers in. It boils down to two questions that the data
mode answers:
1) Is the data binary words or characters?
2) Do you wish to transfer data asynchronously with computing?
The usual answer to the first question is characters, and the
preferable answer to the second question is yes.
If you intend to transfer characters, you get yourself into some
kind of ASCII mode. If you wish to transfer binary data, you get
into some kind of BINARY mode. If you wish to transfer data
asynchronously, which is much more efficient and should be used
wherever possible, you get yourself into some kind of buffered mode.
(all to be explained soon).
I suspect that most often you will want to deal with characters
or text. If so, buffered ASCII mode is the thing for you, so I shall
discuss this first.
To transfer data asynchronously, there must be some core in your
program area set aside to hold the data that the program has (let us
say for output) outputted but the device has not accepted yet. This
space is called buffer area. When you output asynchronously, your
data does not go directly to the device, but is accumulated in a
number of buffers in your core area until the device is ready to
accept the data. Similarly on input, the devices goes ahead as fast
as it can filling buffers for you. You may then take the data out of
the buffers and process it at an orderly rate. Since all the filling
and emptying of buffers by the device is invisible to the user, there
is little use talking about it here. For all practical purposes, it
is as if the buffer is the device.
OK, more about the details of buffers. The monitor will set up
for each device you INIT a ring of buffers in the area above your
program automatically. The only thing you have to supply is a
three-word block of core in your program that you and the monitor can
use to tell what buffer you are currently working on. This
three-word block is specified at INIT time and contains the address
of the current buffer, the byte pointer to the data in that buffer,
and the count of the number of words of data in the buffer. You do
transfers by incrementing the count and you get your data by using
the byte pointer. The three-word block is called your "buffer
header". If you do both input and output to the same device, you
II.B-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
still need two separate buffer headers. One for input and one for
output.
Now for some specifics. Buffered ASCII mode is mode number zero.
If you were to INIT a device, you must specify the following
information: the buffer header addresses, the data mode, the channel
number, and the device name. This is done as follows: the
accumulator field of the INIT instruction is the channel number. The
address portion of the INIT instruction is the mode number. The name
of the device in SIXBIT notation goes in the word after the INIT
instruction. For a list of the legal device names, see section
I.B.8.c which tells the devices that are available at Stanford and
their system names. The next word contains the addresses of the
buffer headers for this channel. The address of the output buffer
header, if any, goes in the left half and the address of the input
buffer header, if any, goes in the right half. The next word is
where the system goes if the device is not available to you at this
time. This is the error return. The word after that is the normal
successful return.
If you were to INIT the disk in mode zero and your input buffer
header were at a place in your program called FOO, your program might
look like this:
INIT 3,0
SIXBIT /DSK/
FOO
HALT
This initializes the disk for input on channel 3 in ASCII
buffered mode with input buffer header at FOO. If the disk is not
available, this job will halt. You must have set aside three words
at FOO with something like a BLOCK statement in your program.
OK, if you get past this part, you have successfully initialized
the disk for input. For the disk and dectapes, you are not quite
done with initialization, for you also have to specify a file to talk
with. For most devices, there are no file names and you are done
with the initialization at this point, but for disk and dectape, you
must go through some more crap.
To read a file from the disk, you must first initialize the disk
with an INIT as above and then you must do a LOOKUP (section II.D.3)
on that channel number to tell the system what file you wish to read.
The LOOKUP instruction has the channel number in the accumulator
field which must correspond with the channel number given in the
INIT, and the address part is the address of a 4-word block which
contains the file name, the file name extension, and the
project-programmer name of the file you wish to read. The
instruction after the LOOKUP is skipped if the file is successfully
located. It is not skipped if there is some error in your
specification, or if the file does not exist. To repeat, your LOOKUP
might look like this:
II.B-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
LOOKUP 3,ADR
HALT
<the remainder of the program appears here>
ADR: SIXBIT /FILE/
SIXBIT /TMP/
0
SIXBIT / H GG/
This needs a bit of explaination. This instruction will locate
the file called FILE.TMP on H,GG's disk area and halt if it is not
found. As you see, the file name goes in the first word of the
4-word block, the file name extension goes in the second word, the
third word is arbitrary, and the fourth word contains the
project-programmer name of the owner of the file, or zero if it is on
your area. The LOOKUP and the HALT instructions should be in one
part of your program and the four words I have called ADR above
should be in another part. They cannot just be directly in line.
The reason there is that zero at ADR+2 is because if the LOOKUP
succeeds, the system gives you some information back in ADR+2 and
ADR+3. See section II.D.3 for all the pertinant details.
Now that you have successfully looked up the file you wish to
read, you are done initializing the file and you may now start
transferring data.
The steps involved in transfering data are as follows: first you
decrement the count. If it is exhausted, you must move on to the
next buffer. If not, you use the byte pointer to get your character.
If your buffer header is called HEAD, then HEAD+1 contains the byte
pointer and HEAD+2 contains the count. You advance yourself to the
next buffer by doing an IN UUO, described in full in section II.D.4.
The IN will skip if there is any error, and not skip if all is OK.
If you were to write a little program to get the next character, it
might look like this:
GETCHR: SOSG HEAD+2
IN 3,
JRST GETCH1
HALT
GETCH1: ILDB CHR,HEAD+1
POPJ P,
This little routine is called with a PUSHJ P,GETCHR and gives you
the next character in the accumulator called CHR. This routine halts
when an error occurs, but that is not really the right thing to do
since end of file (you get end of file when there is no more data to
input) is considered an error also by this routine, and when there is
no more data, you will probably want to do something else than just
II.B-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
halt.
The above routine is written with the assumptions that you have
INITed and looked up the file on channel 3, and that HEAD is the name
of your input buffer header.
This is all for input. The only difference for output is that
you use an ENTER rather than a LOOKUP and an OUT instead of an IN and
an IDPB instead of an ILDB, and the name of your output buffer header
rather than HEAD which is the name of the input buffer header in the
example above. With all of this in mind, and assuming that you know
a little about FAIL, the assembler, you ought to be able to read the
following program. This program takes data from a file called FOO
and transfers it to a file called BAZ, both on the user's data area.
II.B-5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
; THIS IS A SAMPLE PROGRAM FOR DEMONSTRATION PURPOSES
; THIS PROGRAM IS WRITTEN IN FAIL AND MAKES A
; COPY OF THE FILE FOO ONTO A FILE CALLED BAZ
TITLE DEMO ; EVERY PROGRAM OUGHT TO HAVE A TITLE
CHR←1 ; THIS DEFINES ACCUMULATOR 1
P←2 ; THIS WILL BE OUR PUSHDOWN POINTER
START: MOVE P,[IOWD 5,PDL] ; THIS SETS UP OUR PUSHDOWN POINTER
INIT 1,0 ; WE WILL INITIALIZE FOO ON CHANNEL 1
SIXBIT /DSK/ ; DEVICE NAME
IBUF ; INPUT BUFFER HEADER ADDRESS
HALT ; HALT ON FAILURE
LOOKUP 1,INAME ; LOCATE THE FILE FOO
HALT ; HALT IF IT IS NOT THERE
INIT 2,0 ; WE WILL GET BAZ ON CHANNEL 2
SIXBIT /DSK/
XWD OBUF,0 ; OBUF IS OUR OUTPUT BUFFER HEADER, IN THE LEFT HALF
HALT ; HALT ON FAILURE
ENTER 2,ONAME ; SET FILE NAME BAZ FOR OUTPUT
HALT ; HALT IF WE CANNOT OUTPUT
LOOP: PUSHJ P,GETCHR ; GET A CHARACTER
PUSHJ P,PUTCHR ; OUTPUT IT TO BAZ
JRST LOOP ; LOOP AROUND FOR NEXT CHARACTER
GETCHR: SOSG IBUF+2 ; DECREMENT CHARACTER COUNT
IN 1, ; COUNT EXHAUSTED, ADVANCE TO NEXT BUFFER
JRST GETCH1 ; SUCCESS, GET THE NEXT CHARACTER.
STATO 1,20000 ; TEST BIT 22 FOR END OF FILE
HALT ; NOT END OF FILE, SOME OTHER ERROR SO HALT
CALL [SIXBIT /EXIT/] ; END OF FILE, LEAVE AND TERMINATE THE PROGRAM
GETCH1: ILDB CHR,IBUF+1 ; GET CHARACTER FROM BUFFER
POPJ P, ; RETURN WITH CHARACTER
PUTCHR: SOSG OBUF+2 ; DECREMENT CHARACTER COUNT
OUT 2, ; OUTPUT THIS BUFFER
JRST PUTCH1 ; SUCCESS, DEPOSIT CHARACTER AND LEAVE
HALT ; HALT ON ANY OUTPUT ERROR
PUTCH1: IDPB CHR,OBUF+1 ; DEPOSIT CHARACTER IN OUTPUT BUFFER
POPJ P, ; RETURN
OBUF: BLOCK 3 ; SET ASIDE 3 WORDS FOR BUFFER HEADERS
IBUF: BLOCK 3
INAME: SIXBIT /FOO/
0 ; NO FILE NAME EXTENSION
0 ; CREATION DATE WILL COME HERE
II.B-6
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
0 ; AND WORD COUNT WILL COME HERE
ONAME: SIXBIT /BAZ/
0
0
0
PDL: BLOCK 5 ; THIS IS OUR PUSHDOWN LIST
END START ; END OF OUR LITTLE PROGRAM
II.B-7
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
This little sample program illustrates many points. You notice
we initialized each file with an INIT first to open the disk and
assign a channel number and buffer header. We then did a LOOKUP or
an ENTER to extablish a file name. Data was then transferred by two
little routines which used the IN and OUT UUOs to advance buffers.
End of file was tested for with a STATO instruction which is written
up in section II.D.12, and we got out of the program and back to the
monitor by doing an EXIT UUO which is described fully in section
II.D.17.
You may have noticed that there is one phase of IO programming
that I have not discussed, and that is releasing your device when you
are done. We did not need that in our little program because the
EXIT UUO does all that for you. If you do not plan to exit
immediately, you should explicitly release the device yourself.
There are two flavors of releasing a device. You may do a CLOSE
UUO which releases the file but not the device, and there is the
RELEAS UUO which releases everything on that channel. Both of these
UUOs take the channel number in their accumulator field. They are
both written up in section II.D.5. In short, CLOSE undoes any LOOKUP
or ENTER that may have been done on that channel. After you give a
CLOSE, you may immediately do another LOOKUP or ENTER on that channel
number. If, however, you do a RELEAS UUO, this undoes the INIT, so
you must start all over from the beginning.
For devices that do not have directories like the disk and
dectapes do, you may either omit the LOOKUP and ENTER UUOs, or you
may include them anyway and be assured that you will always get the
successful exit.
The next thing I wish to discuss is the other modes you may wish
to work in. In the sample program, data is transferred in 7-bit
bytes. This means that bit 35, the right-most bit, of each word is
not transferred, because a 7-bit byte pointer picks up 5 7-bit bytes
from every word and does not affect bit 35. If you wanted to
transfer the entire word correctly, which you must do to copy a file
with line numbers, you might want to use mode 10. This is called
IMAGE mode and is in actuality a 36-bit buffered binary mode. The
only thing that is different about it is that you get a 36-bit byte
pointer in your buffer header, and the count in the buffer header is
the number of words rather than the number of characters. If we
changed the second instruction of the program from INIT 1,0 into INIT
1,10 then we would operate in 36-bit IMAGE mode instead of ASCII
mode, and all other parts of the program would remain the same. The
program would do exactly the same thing except that it would copy bit
35 in each word correctly.
For completness, I feel I should discuss the unbuffered modes,
although I do not reccomend their use because of the corresponding
loss of efficiency involved. When you use an unbuffered mode, you do
not have to specify buffer header addresses, they are ignored if they
are included. You do not have byte pointers or buffers or whatever.
Your transfer is done by giving an IN or OUT UUO with the address of
II.B-8
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
the UUO pointing to a command list. Mode 17 is called DUMP mode and
is the commonly used unbuffered mode. Normally, your IN or OUT UUO
does not use the address field, but uses only the accumulator field
to specify the channel number. In DUMP mode, the accumulator field
still contains the channel number, but the effective address must
point to (in the simplest case) a 2-word block, the first word of
which is an IOWD and the second word of which must be zero.
An IOWD is a single word that specifies the address where the
data goes and the count of the number of words you wish to transfer.
The format is as follows: The left half of an IOWD contains the
negative of the number of words you wish to transfer. The right half
is the address of the word immediately before (not at, but before)
the first word of the data.
You still have to do LOOKUPs and ENTERs in dump mode, as in any
other mode. This is an example of a dump mode command and
corresponding command list which transfers 500 words from a place
called FOO:
OUT 3,ADR
<remainder of program>
ADR: XWD -500,FOO-1
0
Instead of writing the command word as XWD -500,FOO-1 I could
have taken advantage of the FAIL pseudo-op called IOWD and have
expressed the command word as IOWD 500,FOO and let FAIL take care of
the rest.
For more information on this sort of thing, you should read all
of section II.C, for that will describe in detail all the possible
modes and their contingencies.
II.B-9
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.C DATA REPRESENTATIONS AND SYSTEM STORAGE
II.C.1 DATA MODES - IO STATUS BITS
There is associated with every device on the system a word called
the device IO status word. The right half of this word is used to
communicate with the user. The user sets this half-word initially
(see INIT UUO) and any error conditions detected by the device cause
bits to be set in the status word. These bits may be tested by the
user (see STATZ, STATO, GETSTS, and SETSTS). This is a list of the
bits that are common to all devices:
BIT MNEMONIC MEANING
18 IOIMPM Improper mode.
19 IODERR Device detected parity error.
20 IODTER Device detected data error.
21 IOBKTL Record number out of bounds.
22 IODEND End of file.
23 IOACT Device is active.
24-29 Unused or peculiar to the device.
30 Inhibit input read-ahead.
31 IOWC Inhibit system computation of word count.
32-35 Data mode.
IOIMPM can mean many things. This is the catch-all error bit.
If you attempt to write on a write-locked dectape, you get this error
bit. If you initialize a device in a mode that is not legal for that
device, you get this error bit.
IODERR and IODTER mean there is bad data somewhere along the
line, but it definitly means hardware problems and nothing your
program did. Occurances of these bits imply something wrong with the
device and should be reported in the hardware log.
IOBKTL occurs when you fill up a dectape, or give an invalid USET
(see USETI, UGETF, USETO UUOs) pointer. It simply means the record
number in question is invalid. This only occurs for devices with
numbered records, like dectapes and the disk.
IODEND only occurs on input and means there is no more data. A
CLOSE or RELEAS UUO will definitely clear the bit. You may not do
further input when this bit is on, because there is no more data!
Bit 30 is supposed to make buffered output (or input)
synchronous. That is, it is supposed to force one and only one
buffer to be transmitted for every UUO. Normally, the device
transferrs data at its own rate and stops when there are no more
buffers to operate on. There are some devices, dectape and disk to
be exact, that will do whatever they want regardless of this bit.
IOWC forces the system to believe the word count in the first
word of the buffer itself. Normally, when you do an OUTPUT UUO, the
system picks up your byte pointer in the buffer header block (see
section II.C.3, entitled "BUFFER RINGS"), computes how many words you
must have deposited, and stores that number in the first word of the
II.C.1-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
buffer itself. This bit inhibits that calculation and sends whatever
was in that word on to the device as gospel. This bit has no effect
in unbuffered modes.
Bits 32-35 are the data mode. There are seven legal modes:
MODE NAME MEANING
0 ASCII mode. 7-bit byte pointer. Buffered mode.
1 ASCII line mode. 7-bit byte pointer. Buffered mode.
10 IMAGE mode. 36-bit byte pointer. Buffered mode.
13 IMAGE BINARY mode. 36-bit byte pointer. Buffered mode.
14 BINARY mode. 36-bit byte pointer. Buffered mode.
16 DUMP RECORD mode. Unbuffered mode.
17 DUMP mode. Unbuffered mode.
ASCII mode is what you use for text devices, like the teletype,
the line printer, or anywhere that you want to receive data one
character at a time.
ASCII line mode is the same as ASCII mode except on teletype
input. There it means that an INPUT UUO will return when a
carriage-return, line-feed, or alt-mode is typed, rather than just
when the buffer is filled. What I mean is that unless you are in
ASCII line mode, you will get hung at the INPUT UUO until the typist
has typed 80 or so characters, regardless of how many
carriage-returns he has typed.
IMAGE mode is a buffered binary mode. In this mode, you read or
write one word at a time. You may read text files this way, in which
case you will get five characters in every word. This mode is used
by assemblers and compilers to write and read .REL files. For a
discussion of the significance of .REL and .DMP files, see sections
I.B.4.f and the tail end of II.A.
IMAGE BINARY mode is the same as image mode for everyone but the
paper tape reader and punch, there it means unblocked, unchecksummed,
format.
BINARY mode is the same as image mode for everyone but the paper
tape reader and punch, there it means every buffer is written as a
block with its word count at the front and its checksum at the end.
The word count and checksum are deleted on input.
DUMP RECORD mode is the same as DUMP mode for every device except
the Magnetic tapes. There it means transmit the data to the device
in 200-word records, whereas DUMP mode would transmit the data as one
very large record. If you write a tape in DUMP mode, it can only be
read back in in DUMP mode, but if it is written in DUMP RECORD mode,
it may be read back in in any mode.
DUMP mode is an unbuffered mode. This means that with every
INPUT or OUTPUT UUO, you must specify the number of words you want
transferred and the address in your core that these words are to come
from. You do this by means of the dump mode command list (see
section II.C.2, entitled "DUMP MODE COMMAND LISTS"). The INPUT or
OUTPUT UUO does not return until the transfer is complete. This is
II.C.1-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
different from buffered mode in that in buffered mode, transfers are
going on to the buffers in your core while you are computing, that
is, asynchronously with your program. DUMP mode is used by the SAVE
and GET commands (see section I.B.5, entitled "COMMANDS TO MANIPULATE
CORE IMAGES").
Each of these modes has a slightly different meaning for each
different device. To be sure about the mode you chose, please see
the programming description of the particular device you are
interested in.
II.C.2 DUMP MODE COMMAND LISTS
The effective address of an INPUT or OUTPUT UUO in dump mode must
be the address of a dump mode command list. This list is at least
two words long. A dump mode command is basically one word. The left
half is the negative of the number of words you wish to transfer, the
right half is the word before the first word you want transfered.
The reason a command list is at least two words long is that there
must be at least one command, and a zero to indicate no further
commands.
In the assembly languages, there is a pseudo-op called IOWD that
generates dump mode commands. The line IOWD N,LOC generates XWD
-N,LOC-1. This is a word with the negative of N, the word count, in
the left half, and one before LOC, the starting address, in the right
half. This will cause all the words between and including LOC and
LOC+N-1 to be transfered.
You do not have to make your commands in line. If in your
command list there appears a word with zero in the left half, it
directs the system to take the next command from the address in the
right half of that word. For example, this command list:
LIST: IOWD 50,LOC1
IOWD 20,LOC2
0
Is exactly the same as this command list:
LIST: IOWD 50,LOC1
LIST2
LIST2: IOWD 20,LOC2
0
The only difference is that in the second example, the commands were
in two different places rather than being directly in line.
If you gave an OUTPUT CHAN,LIST command and if you were in dump
mode, this command list would cause 50 words to be read out of LOC1,
II.C.2-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
and 20 words to be read out of LOC2. If you at some later time gave
an INPUT CHAN,LIST and if you were in dump mode, you would get back
those same 50 words at LOC1 and those same 20 words at LOC2.
There is a maximum of 144 commands any single dump mode command
list may have. If any of the addresses in any of the commands point
to places that are not in your core image, you will get the error
message "ADDRESS CHECK".
II.C.3 BUFFER RINGS
When you are in one of the buffered modes, a ring of buffers will
be set up in your core area for temporary storage of input-output
data while the device is active. This allows the user to fill
(empty) a buffer while the device empties (fills) another buffer
independently. A reasonable degree of effeciency can be achieved
this way by allowing both the user and the device to operate at their
own rates.
To initiate a ring of buffers, you must have given the address of
a free 3-word block in your INIT UUO that the system may use to store
information about what buffer the user is currently filling
(emptying), the byte pointer to the data itself, and the count of the
amount of room left in the buffer. This 3-word block is called the
"buffer header".
The first word of the buffer header contains the address of the
current buffer in the right half. The sign bit is set to 1 when the
buffers are created, and is cleared to zero when the first INPUT or
OUTPUT UUO is given. The sign bit tells whether the buffers have
been used at all.
The second word of the buffer header is the byte pointer to the
data. It is set so you may get each successive byte (7 or 36 bit) of
data by doing an ILDB (IDPB on output) with the second word of the
buffer header as the address of the ILDB (IDPB) instruction.
There is a great illustration of buffer rings in the DEC
TIME-SHARING MONITOR manual on page 4-11, figure 4-2. This picture
(worth 1K words) explains the linkages better than I can. I will
describe them anyway.
The first two (usually three) words of each buffer are used by
the system and contain no data. The first word contains the device
status bits at the time that buffer was transferred. The second word
has the address of the next buffer in the ring (may point to itself)
in the right half, and the size of the buffer, minus 2, in the left
half. The sign bit of the second word is set to 1 when the buffer is
full of data and cleared to zero when it is empty. Note that all
pointers to buffers, both in the buffer header and from one buffer to
the next, point not to the first word of the buffer, but to the
second word, where the pointer to the next buffer is.
The ring use bit (sign bit of the second word) actually means the
buffer is full of data. On output, this means the user has filled it
II.C.3-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
and the device has not yet emptied it. On input, this means the
device has filled it and the user has not emptied it yet.
The third word of the buffer contains the count of the number of
data words in the buffer. This count is computed, on output, from
the byte pointer in the buffer header (unless the IOWC bit in the
status half-word is on. See section II.C.1, entitled "DATA MODES -
IO STATUS BITS"). On input, it is determined by how much data the
device has ready. This word is not transmitted to most devices. The
individual device descriptions will say whether a given device does
or does not transmit this word. In any case, you will not get that
word as data when you input that data again. It is as if that word
were invisible.
If you initialize a device in buffered mode with IOWC on in the
mode bits, the system will not compute that word count from your byte
pointer. Instead, you must specifically place the word count there
yourself. Many devices will balk at a word count larger than their
standard buffer size, and other devices will ignore data in a buffer
past a certain point. There are at least three devices which can
accept buffers of any size, and these are the line printer, the
teletypes, and the magnetic tapes.
Some more discussion for clarity might be in order here. The
sign bit in the buffer itself means the buffer is full of data and
waiting for something. If it is output, it means the user has filled
it and the device has not taken it yet. If it is input, it means the
device has filled it and the user has not taken it yet.
The illustration below may help you in absorbing the structure of
the buffer rings.
II.C.3-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
DIAGRAM OF A 2-RING BUFFER
BUFFER HEADER
****************\
* S * Pointer ***********
****************/ *
* Byte Pointer * *
**************** *
* Byte Count * *
**************** *
*
**********************************
*
* FIRST BUFFER
*
* *******************
* * IO Status Bits *
* \ *******************\
********* S * Pointer ********
* / *******************/ *
* * Word Count * *
* ******************* *
* * * *
* * Data * *
* * * *
* * * *
* * * *
* ******************* *
* *
***************************************
* *
********************************** *
* SECOND BUFFER *
* *
* ******************* *
* * IO Status Bits * *
* \ *******************\ *
********* S * Pointer *************
/ *******************/
* Word Count *
*******************
* *
* Data *
* *
* *
* *
*******************
II.C.3-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.C.4 JOB DATA AREA
The first 140 words of each core image is storage for a great
deal of information about the job. The user may read this
information at any time to find out his current core size, his APR
trap enablings, whether DDT or RAID is in core, or any of a number of
things. I shall present a list of the names of the things that are
stored there followed by a list of their explainations.
Some of this data belongs to the monitor. As a matter of fact,
to keep the user from destroying important data, the area from JOBPRT
to JOBPFI is moved into the monitor when a job is run. When the job
is shut off for any reason (timed out, swapped out) the data is moved
back to the area to conserve space in the monitor and since the user
is not operating then, he cannot harm the data. This also means that
the user may not alter this data directly, because it is not really
there. You must use special instructions (like the SETDDT UUO) to
alter those locations.
If you need to refer to these locations, you should do so
symbolically, that is, you should refer to these locations by their
mnemonics, rather than their absolute octal addresses. The reason
for this is that we may decide to juggle these locations around from
time to time and if you refer to them symbolically, it is little or
no trouble to keep your programs up to date. There is a file on the
system library files called JOBDAT.REL which contains the latest
definitions of all these symbols. If you place all the symbols of
this nature you use in an EXTERNAL statement, the Loader will go to
the system files for their definitions. This means that every time
these locations are changed, everyone must reload their programs.
II.C.4-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
WORD MNEMONIC OTHER NAME (IF ANY)
0 JOBAC
20 JOBDAC
40 JOBUUO
41 JOB41
43 JOBENB
44 JOBREL JOBPDL
45 JOBPD1
72 JOBHCU JOBPRT
73 JOBPC JOBSAV
74 JOBDDT
75 JOBJDA
114 JOBPFI
116 JOBSYM
117 JOBUSY
120 JOBSA
121 JOBFF
122 JOBS41
123 JOBEXM
124 JOBREN
125 JOBAPR
126 JOBCNI
127 JOBTPC
130 MOBOPC
131 JOBCHN
132 JOBFDV
133 JOBCOR
140 JOBDA
JOBAC is where the user's accumulators are stored over a clock
trap or a UUO call.
JOBDAC is where the system's accumulators are stored when a job
goes into a wait state of some type, the most common of which being
IO wait.
JOBUUO is where user UUOs (op codes 001 to 037) are placed. The
effective address calculation has already been done, so the index and
indirect fields of the UUO are zero.
JOB41 must contain the address of a routine to JSR to when a user
UUO (op codes 001 to 037) occurs.
JOBENB is where a user's APR trap enabled bits are stored. See
the APRENB UUO for details.
JOBREL is where the last legal location in the core image is
stored. If your core image was 1K long, the number 1777 would be
placed here.
JOBPD1 is the start of the pushdown list the monitor uses during
a UUO call. JOBPDL is defined as one before this.
JOBHCU is the number of the highest channel in use. This is the
II.C.4-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
first location that is copied into the monitor when your job is
running. JOBPRT is the symbol the system uses to BLT the saved part
into the monitor itself.
JOBPC is where your program counter word is stored when your job
is not running.
JOBDDT contains the address of DDT or RAID in your core image.
If neither is present, this location is zero. You may set this to
any value you wish by use of the SETDDT UUO. This is the first
location written out by a SAVE command (see section I.B.5). The
symbol the system uses when it saves or gets a job is JOBSAV.
Perhaps you are wondering why JOBSAV and JOBDDT are not defined to be
the same location. JOBSAV is one before JOBDDT because dump mode
command lists expect not the address of the first word of the
transfer but one before the address of the first word of the
transfer.
JOBJDA is 20 words long and contains the address of the device
data blocks in the system of each device you have initialized in
channel number order. The address of the data block for channel 6 is
in JOBJDA+6, and so on. JOBPFI is the end of the part of the data
area that is BLTed into the system when your job runs.
Note that you can not depend on anything from JOBPRT to JOBPFI to
be up to date, because this data is only sent back to your core image
when you get shut off, either by exceeding your time allotment with
someone else waiting for you, or by entering a wait state.
JOBSYM contains the pointer to your symbol table. If you do not
have your symbols in your core image, this word will be zero. The
left half of this word is the negative of the count of the number of
symbols. The right half is the address of the symbol table (NOT the
first location minus one, just the first location).
JOBUSY points, with the same format as JOBSYM, to the list of
undefined globals generated by the loading process. This list is
always included, whether you have DDT or not, and it is zero if the
loading process was completly successful.
JOBSA contains, in the right half, the pointer to the starting
location of your program. Every time you say START or CSTART, your
program is started at this address. The left half of this word
contains the address of the first location above the symbol table (or
above the programs if no symbol table) in your core image. When you
do a CALL [SIXBIT /RESET/] (or CALLI 0), JOBFF (see below) is reset
to this number.
JOBFF is the first location beyond your program or symbol table.
The space from here to the address in JOBREL are not used. The
system sets up IO buffers here. Every time a buffer is set up, the
value of JOBFF is changed to point above the buffer, and every time a
RESET UUO is given, the value of JOBFF is reset to the number in the
left half of JOBSA.
JOBS41 is where the contents of JOB41 are saved when you do a
SAVE command or a SWAP UUO. If you notice, locations 0 to 71 are not
saved by a SAVE command, and JOB41 is down there. In an attempt to
II.C.4-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
preserve JOB41 over SAVE and GET, it is put in JOBS41 before the core
image is written on the disk, and it is restored when the core image
is read from the disk.
JOBEXM is a temporary cell used by the EXAMINE and DEPOSIT
(undocumented) commands.
JOBREN is the place your program should put the address of the
place it should be restarted when the REENTER command is given. (see
section I.B.6, entitled "COMMANDS TO START A PROGRAM"). If no
address is placed here by your program, a REENTER command will not do
the right thing.
JOBAPR contains the address of the routine you wish the system to
go to when an APR trap occurs. Your program counter word at the time
of the trap is stored in JOBTPC, and the APR flags at the time of the
trap are placed in JOBCNI. See the APRENB UUO for details.
JOBCNI is where the APR flags are stored when an APR trap occurs.
JOBTPC is where the program counter word is stored when an APR
trap occurs.
JOBOPC is where the program counter word is stored when you start
your program using a START, CSTART, DDT, or REENTER command.
JOBCHN is used for FORTRAN chaining.
JOBFDV is temporary storage for the FINISH command.
JOBCOR is temporary storage for SAVE and GET commands.
JOBDA is where your programs start.
II.C.5 TEXT REPRESENTATIONS
There are five standard ways to represent text on the PDP-10.
First, there are ASCII strings.
ASCII
This means 7-bit bytes, packed 5 to a word, with bit 35 always
zero in each word. The octal representation for each of the
characters is given in section I.C.5, entitled "STANFORD CHARACTER
SET".
ASCIZ
An ascii string may be of any length. It is for this reason that
we use what are called ASCIZ strings, which are ascii strings with
the last byte always being a null character, octal 000. Placing the
null character at the end of the string removes any ambiguity as to
the length of the string. Asciz strings are used in the DDTOUT UUO.
ASCID
Line numbers are distinguished from regular ascii text by placing
a one in bit 35. It is for this reason that line numbers are
restricted to 5 characters. You may produce strings of text with bit
35 on by using ASCID representation.
The III display processor when displaying text requires that bit
II.C.5-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
35 be on also. The ASCID representation may be used directly to
generate text for the display processor.
SIXBIT
Since things like device names and file names are all upper case
letters or numbers, one does not need all 7 bits to express these.
For this reason, we define SIXBIT representation as the ascii octal
code for the character minus 40 modulo 100. Sixbit characters are
packed 6 to a word with no room left in the word.
RADIX50
In all the above representations, there is a clear mapping from
particular bits in a word to the character the octal code contained
in those bits represents. In ascii mode, you know the first
character occupies bits 0 through 6, the second character occupies
bits 7 through 13, and so on. In RADIX 50 representation, there is
no such correspondance. The general form, however, is very similar
to that of other representations in this sense. If we recognize that
a sixbit word is of the form:
C1*100↑5 + C2*100↑4 + C3*100↑3 + C4*100↑2 + C5*100 + C6
where C1 to C6 are the octal character values of each of the six
characters in the word, then we might understand it when I say that
radix 50 words are of the form:
C1*50↑5 + C2*50↑4 + C3*50↑3 + C4*50↑2 + C5*50 + C6
The octal codes are 01 to 12 for the digits (ascii code minus
57), 13 through 44 for the letters (ascii code minus 66), 45 for
period, 46 for dollar sign, and 47 for percent sign. The way you
decode a word in this representation is by successivly dividing the
word by 50. The remainder each time you divide is another character.
The characters come out in reverse order this way. This
representation leaves bits 0 through 4 unused. Symbol tables in DDT
and RAID use radix 50 representation.
Note that all text information except radix 50, and
project-programmer names in sixbit, is left adjusted in the word.
II.C.6 SYSTEM PARAMETER REPRESENTATIONS
File names and file name extensions are stored, left-adjusted, in
sixbit representation. For example, the name FOO would be
represented by the octal number 465757000000. File names are from
one to six characters long, and file name extensions are a maximum of
three characters long.
Device names are left-adjusted in sixbit representation. For
example, the device name MTA0 would be represented by the octal
number 556441200000.
Project-programmer names are stored right-adjusted in sixbit, one
II.C.6-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
half word each. For example, the name 1,3 would be stored as
000021000023. The name S,SYS would be stored as 000063637163.
Dates are returned as one number in the form
((year-1964)*12+(month-1))*31+day-1, where l964, 12, and 31 are
decimal numbers. This means you can take this number and get the day
by dividing it by 31 and adding one to the remainder, which makes the
remainder into the day. If you divide the quotient by 12, the
remainder will be one less than the month number, and the new
quotient will be the number of years since 1964.
II.C.6-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D UN-USED OPERATION CODES (UUOs)
II.D.1 UUOs TO INITIALIZE DEVICES
INIT UUO 041
INIT <channel number>,<data mode>
<device name in SIXBIT>
XWD OBUF,IBUF
<failure return>
This and OPEN are the UUOs you use to initialize a device. This
tells the system what device you want, what mode you want to use it
in, and where your buffer headers are. The system takes the failure
return if there is some error in your specification, or if the device
is not available at this time. For a list of legal device names, see
section I.B.8.C, entitled "ASSIGN COMMAND". For a discussion of the
meaning of the data mode, see section II.C.1, entitled "DATA MODES -
IO STATUS BITS". For a discussion of buffers and buffer headers, see
section II.C.3, entitled "BUFFER RINGS".
Anyway, after you have seen all of those, maybe you can
understand this UUO. If you are initializing the device in dump
mode, the second word (XWD OBUF,IBUF) may be ommitted. If you intend
to do buffered mode input only, OBUF may be ommitted. If you intend
to do buffered mode output only, IBUF may be ommitted.
The channel number is an arbitrary number from 0 to 17 you give
the system so that you may refer to this device in subsequent UUOs by
the channel number alone, not the entire device name. Since you must
do an INIT or OPEN UUO before you may give any other IO UUOs to that
device, the channel number will certainly be defined by the time you
doing the IO UUOs. If you do an IO UUO without first having done an
INIT or OPEN, you will get the message "IO TO UNASSIGNED CHANNEL".
If you have previously initialized a device with the same channel
number, it is released first (see section II.D.5).
The device name is the logical or physical name in sixbit
representation. For an explaination of sixbit representation, see
section II.C.5, entitled "TEXT REPRESENTATIONS".
If the device is busy when the INIT is given, if the IOPAR bit
(1000 bit) in the right half of the IO status word (IOS) is zero, the
system will type out "DEV is busy, will you wait?". If you reply "Y"
to this, or if the IOPAR bit is on, you will be placed in a queue of
jobs that want this device. When the device is released, the first
person in the queue is given first chance to assign the device. If
you reply "N" to the question, you will be asked "Direct IO to
disk?". If you reply "Y" to this, you will be given device DSK
instead of what you asked for.
II.D.1-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
OPEN UUO 050
OPEN <channel number>,ADR
<error return>
ADR: <data mode>
<device name in SIXBIT representation>
XWD OBUF,IBUF
This is the same as the INIT UUO except that the information does
not follow the UUO, but is instead located in the 3 words at the
address specified by the effective address of the UUO.
The left half of the data mode word is ignored.
II.D.1-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.2 UUOs TO SET UP BUFFER RINGS
Before one reads about these UUOs, one should have read section
II.C.3, entitled "BUFFER RINGS". Please note that it is rarely
essential that you give any of the following UUOs. If you do not
give any of them, the monitor will set up buffers for you
automatically. It will even expand your core size to fit them in if
need be.
INBUF UUO 064
INBUF <channel number>,<number of buffers>
This causes a ring of buffers to be set up at the address
contained in JOBFF (see section II.C.4, entitled "JOB DATA AREA").
It sets up as many buffers as specified by the effective address of
the UUO. If the effective address is 0, two buffers are set up. If
there is not enough room between JOBFF and JOBREL for the number of
buffers you asked for, your core is expanded automatically.
If you do not give an INBUF UUO, it will be done for you when you
give the INPUT UUO.
The INBUF UUO also sets up your input buffer header to point to
the first buffer in the ring.
You may cause your buffers to be set up anywhere in your core
area by temporarily changing JOBFF to point to where you want the
buffers to be.
OUTBUF UUO 065
OUTBUF <channel number>,<number of buffers>
This is the same as INBUF except for output buffers. The only
difference between an input buffer and an output buffer is that one
is pointed to by an input buffer header and the other is pointed to
by an output buffer header.
UINBF UUO 704
UINBF <channel number>,ADR
ADR: <number of buffers>
<number of words of data in each buffer>+1
This is the same as INBUF except that the effective address of
II.D.2-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
the UUO is the address of a two word block which contains the number
of buffers you want and the length of the data portion of each buffer
plus one.
This is intended to give buffered magnetic tape service for
nonstandard record lengths. Not all devices will accept nonstandard
buffer sizes. The individual device descriptions should be
consulted.
UOUTBF UUO 705
UOUTBF <channel number>,ADR
ADR: <number of buffers>
<number of words of data in each buffer>+1
This is the same as OUTBUF except that the effective address of
the UUO is the address of a two word block which contains the number
of buffers you want and the length of the data portion of each buffer
plus one.
This is intended to give buffered magnetic tape service for
nonstandard record lengths. Not all devices will accept nonstandard
buffer sizes. The individual device descriptions should be
consulted.
II.D.3 UUOs TO MANIPULATE FILES
LOOKUP UUO 076
LOOKUP <channel number>,ADR
<error return>
ADR: <file name in sixbit representation>
<file name extension in sixbit representation>
<this word is ignored>
<ignored unless disk, then project-programmer name in sixbit>
This UUO does different things for different devices, but it
basically locates a file and prepares the file to be read. If the
file does not exist, the error return is taken. The LOOKUP should be
done soon after an INIT or OPEN, but before the first INPUT UUO, or
the system will not know which file to give you data from! For
devices which do not have directories, this UUO is a no-op and always
takes the success exit. If the device is a dectape, only the file
name and the file name extension are looked at. If the device is the
II.D.3-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
disk, the project-programmer name is needed also. The
project-programmer name may be zero, in which case your
project-programmer name is used, or it may be any legal
project-programmer name. If the project-programmer name is illegal
or does not exist, the error return will be taken.
Since SIXBIT notation is always left-adjusted (except for
project-programmer names) and since file name extensions are only
three characters long maximum, the right half of ADR+1 is not looked
at. It is used to store data upon a successful LOOKUP.
When you give this UUO and get the success exit, the system gives
you back some data about the file that it has on hand. Since this
data is different for the disk and for dectapes, I shall give it to
you for the disk first:
In the right half of ADR+1, you get the date of creation in
system date format. In bits 0 through 8 of ADR+2, you get the file's
protection. In bits 24 through 35, you get the date of creation in
system date format (see DATE UUO). In bits 9 through 23, you get the
time of creation in minutes since midnight. In ADR+3, you get the
negative of the word count of the file, swapped. That is, the
negative (2's-complement) of the length of the file in words with the
left and right halves of the count exchanged. The reason you get the
word count in this form is so we remain compatible with DEC's format.
On dectapes, all you get back is the date of creation in ADR+2 in
system date format. You do not get either time of creation, word
count, or protection (dectapes have no protection system).
The file protection is nine bits long. The first three bits
specify what the owner of the file is allowed to do, the next three
bits tell what the project is allowed to do to the file, and the last
three bits tell what anyone else is allowed to do. Each group of
three bits tells exactly what is protected. Bit 0 on means the owner
of the file may not alter the file's protection. Bit 1 on means the
owner of the file may not read the file. Bit 2 on means the owner of
the file may not write on or delete the file. This is the same for
the other two groups. Bit 3 on means people in the project may not
change the protection of the file, and so on.
When a file is created, it is given initially a protection of
005, meaning anyone in the same project may read, write, delete,
rename, or change the protection of the file, but noone outside the
project will be able to do anything but read the file. If you set
the protection of a file to 055, then anyone may read the file, but
only the owner may delete it or change the protection. This is the
DEC standard protection mode (but not our standard). If you set the
protection of a file to 777, then noone may do anything to it! This
nine bit number is called the file's "protection key", and may be set
initially by the ENTER UUO, or may be changed with the RENAME UUO.
Protection against reading the file is called "read protection".
Protection against writing or deleting the file is called "write
protection". Protection against changing the protection is called
"protection protection".
II.D.3-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
For purposes of dumping, purging, and restoring the disk, there
is one project-programmer name that is almighty in that no protection
checking is done if this project-programmer name is accessing a file.
This is 1,2. Anyone logged in under 1,2 may read, write, delete or
change the protection of any file, regardless of its protection key.
If a file of yours accidently gets its protection set to something
you can't undo, you may have an expert reset the protection key for
you by logging in under 1,2.
If you do an INPUT on a device which needs a LOOKUP such as the
disk but in fact have not given a LOOKUP UUO, the system will type
"LOOKUP needed. Type file name:". At this point, you may type
control-C to give up, or you may type a file name, in which case, a
LOOKUP on that file name will be done for you automatically.
This is a chart of the data you get back from the disk upon
completion of a successful LOOKUP:
ADR: <file name>
XWD <file name extension>,<date of creation>
<bits 0-8; protection key, bits 9-12; mode written,
bits 13-23; time of creation,
bits 24-35; date of creation>
<negative-swapped word count>
Note that for dectapes, only the creation date in ADR+2 comes
back. Note also that on the disk, you may not do two consecutive
LOOKUPs with the same 4-word block, because if the first one
succeeds, the last word is no longer a legal project-programmer name,
but is instead the negative swapped word count.
ENTER UUO 077
ENTER <channel number>,ADR
<error return>
ADR: <file name in sixbit>
XWD <file name extension in sixbit>,<time of creation>
<bits 0-8, protection key, bits 9-35, creation date>
<project-programmer name>
This UUO opens a file for output. If either the time of
creation, the protection key, or the creation date are non-zero, they
are stored with the file name. If they are zero, the current time
and day are used and the protection is set to 000. For dectapes,
only the file name and the file name extension is needed. For the
disk, you may leave the project-programmer name zero and the file
will be opened on your disk area. If the dectape is full, the error
return will be taken. If the project-programmer name you give is
II.D.3-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
illegal or does not exist, the error return is taken. If the file is
already being written or modified, the error return is taken. If the
file is being read, it is not really deleted, but is held in suspense
until all references to it are closed, then if a file has been
written out, the old file will be deleted. Note that the old file is
not deleted until a CLOSE or RELEAS UUO (see section II.D.5) is given
by the program that is writing the file.
When the error return is taken with the disk, the right half of
ADR+1 is set to the error code 0, 3, or 6. These are explained fully
under the RENAME UUO, but briefly, this is what they mean. Error
code 0 means your file name is zero. Code 3 means a file protection
violation has occurred. Code 6 means you have already done a LOOKUP
and the file name disagrees with the name given in the LOOKUP.
This UUO must be done after the INIT or OPEN UUO, but before the
first OUTPUT UUO is given. As with the LOOKUP UUO, if you do not do
an ENTER before you do an OUTPUT, and an ENTER is needed, the system
will ask you for the file name.
RENAME UUO 055
RENAME <channel number>,ADR
<error return>
ADR: <new file name or zero for deletion>
XWD <new extension, zero for delete>,0
<bits 0-8; new protection key, bits 9-35 are ignored>
<new project-programmer name>
This UUO, when given after a successful LOOKUP, causes some of
the data about the file to be changed, specifically, the file name,
the extension, the protection or the project-programmer name, or if
the file name and file name extension are both zero, causes the file
to be deleted (or if someone is still reading the file, to be marked
for deletion when all read references are completed).
The error return may be taken for a variety of reasons. When the
error return is taken, a number between 0 and 7 is placed in the
right half of ADR+1. These codes have the following meanings:
0
This means the file specified by the LOOKUP is not there any
more, or you have done a LOOKUP or ENTER with a zero file name, or a
LOOKUP on a file which does not exist.
1
This means the project-programmer name in ADR+3 is not a legal
one.
2
II.D.3-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
You get this error if the file is protected from your meddling.
This indicates a protection violation of some sort.
3
This means the file is busy, that is, being referenced by someone
else at the current time and your RENAME can not be done at present.
4
You get this error if you are changing the file name or the file
name extension and the name you are changing it to already exists.
5
This means a successful LOOKUP has not been done yet.
6
You don't get this error code from a RENAME, but if you do a
LOOKUP and an ENTER on the same channel with different file names,
this error will be given.
7
You get this error exit if you have not given an INIT or OPEN
yet.
When the error return is taken, you are disconnected from the
file. You will have to do another LOOKUP (and/or ENTER) to transfer
any data with the file.
You may use this UUO to change the file name, the file name
extension, the protection key or the project-programmer name of any
file that is not protected from you. You may change all of this data
in one RENAME UUO if you wish. You must include in their original
state all the data you do not wish to change. For example, if you
LOOKUP a file named FOO.TMP and wish to change its name to BAZ.TMP,
you must include the file name extension TMP in ADR+1 of your 4-word
RENAME block or else you will not end up with the desired file name
extension. If you are changing the file name, you must put the old
protection key in bits 0-8 of ADR+2 or the key will be set to
whatever is in bits 0-8 of ADR+2. If you are just changing the
protection key, then the file name, the file name extension, and the
project-programmer name must be set right or your file may end up
with the wrong name or even on an alien disk area!
If the project-programmer name is zero, it is taken to be your
project-programmer name.
If the file name and the file name extension are zero, and if the
project-programmer name matches the one given in the LOOKUP, then the
file will be marked for deletion. If no one is reading the file, or
when all read references are complete, the file will be deleted.
II.D.3-5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.4 UUOs TO DO DATA TRANSFERS
IN UUO 056
IN <channel number>,ADR
<successful return>
<error return>
This UUO causes one unit of data to be transferred. If in
buffered mode, causes at least one buffer to be filled with input
data and causes the byte pointer and count in the buffer header to be
set to the freshly filled buffer. In dump mode, ADR is taken to be
the origin of a dump mode command list, and the UUO causes all the
data indicated by the command list to be transferred. In buffered
mode, ADR is ignored.
If any error occurs, or if there is no more input data, then the
UUO skips. More specifically, if when the UUO is about done, if any
of the bits IOBKTL, IODTER, IODERR, IOIMPM, or IODEND (see section
II.C.1) are on, the skip return is taken.
In buffered mode, when end-of-file occurs, the UUO skips and at
that point, there is no more data to be had. In dump mode, if
anytime during the processing of the command list the file is
emptied, the end-of-file bit (IODEND) will come on and the UUO will
skip, but unlike the buffered mode case, data may well have been
transferred. There is no way of telling exactly how much data you
got in dump mode.
On the teletype, end-of-file occurs when control-Z (circumflex)
is typed. This is the only thing that causes IODEND to come on in
the case of the teletype.
INPUT UUO 066
INPUT <channel number>,ADR
This is exactly the same as the IN UUO except that no error bit
checking is done and the UUO never skips.
OUT UUO 057
OUT <channel number>,ADR
<successful return>
<error return>
This causes one unit of data to begin to be transferred to the
device. If in buffered mode, causes the buffer header to be advanced
to the next empty buffer the user may fill and if the device is not
already running, causes the device to be started. If in dump mode,
II.D.4-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
ADR is taken to be the origin of a dump mode command list and causes
all the data specified by the command list to be transferred before
the UUO is done. In buffered mode, ADR if non-zero is taken to be
the address of a buffer ring and your buffer header will then be set
to that buffer. The purpose of this is to allow you to use several
different buffer rings for output and switch among them if you so
wish.
As with the IN UUO, if any of the bits named above (in the
description of the IN UUO) come on during the processing of the OUT
UUO, the UUO will skip.
OUTPUT UUO 067
OUTPUT <channel number>,ADR
This is exactly the same as the OUT UUO except that no error bit
checking is done and the UUO never skips.
II.D.5 UUOs TO TERMINATE IO
CLOSE UUO 070
CLOSE <channel number>,S
This UUO terminates either input or output or both, determined by
S. If S is zero, both input and output will be closed. If S is 1,
only input is closed. If S is 2, only output is closed. If S is 3,
nothing is closed and it is as if the UUO were never given. All but
bits 34 and 35 in the address field of this instruction are ignored.
On non-directory devices like teletype and paper tape, this UUO
doesn't really do anything except flush any buffers that may still
have data in them. On the magnetic tape on output, CLOSE causes two
end-of-file marks to be written on the tape and causes it to
backspace over one of them so that there will be one end-of-file mark
between each pair of files and two end-of-file marks at the end. The
occurance of two consecutive end-of-file marks on the magnetic tape
is called the logical (as opposed to physical) end of tape. On the
disk or dectape, CLOSE causes the input or output side of the data
transfer to be completed and the file is then disconnected. You are
not allowed to do any further data transmission operations until
another LOOKUP (or ENTER) is given.
RELEAS UUO 071
RELEAS <channel number>,0
II.D.5-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
This does a complete CLOSE and then frees the channel number.
This means that after this UUO is given, you must do another INIT or
OPEN to do any more IO on this channel.
II.D.5-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.6 SPECIAL TELETYPE UUOs
In a time-sharing system, the essential control device is the
teletype. It is through the teletype that you start, stop, debug and
otherwise control programs. For reason, one needs a great degree of
flexability in handling the teletype. It is for this reason that
there exists a proliferation of ways to push characters to and from
the teletype. You may, of course, INIT the teletype like a normal
device and use it in that manner. For finer control, you may be
interested in the following UUOs:
TTYUUO UUO 051
TTYUUO <function>,ADR
This is not just one UUO but many, for the accumulator field
(denoted above by "function") is used to distinguish the various
operations. I shall describe the various functions independently as
separate UUOs.
INCHRW TTYUUO 0,
INCHRW ADR
This UUO waits for a character to be typed and then gives it to
you, right-adjusted, in ADR. The CTRL 1 and CTRL 2 keys on the III
displays come in as bits 27 (for CTRL 1) and 28 in ADR.
OUTCHR TTYUUO 1,
OUTCHR ADR
This outputs the right-most seven bits of ADR as one character.
INCHRS TTYUUO 2,
INCHRS ADR
<no character has been typed>
<successful return>
This is like INCHRW except that it does not wait for a character
to be typed. If there is a character ready, it will be placed,
II.D.6-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
right-adjusted, in ADR and the UUO will skip. If the user has not
typed a character yet, the UUO will not skip and ADR will not be
changed.
OUTSTR TTYUUO 3,
OUTSTR ADR
This UUO takes ADR to be the origin of an ASCIZ string and
outputs the entire string on the teletype.
INCHWL TTYUUO 4,
INCHWL ADR
This is the same as INCHRW except that it waits until the user
types an entire line before it gives you a single character. This
raises your processing efficiency greatly and you should use UUOs
like this as much as possible. This is called "line mode" input and
means nothing happens until an entire line has been typed.
To restate, if the user has typed a line, this UUO will get the
next character of it and place it right-adjusted in ADR. Otherwise,
it will wait until the user has typed a line (or 64 characters,
whichever comes first) before it gets the next character.
INCHSL TTYUUO 5,
INCHSL ADR
<full line has not been typed yet>
<successful return>
This UUO gives you one character, right-adjusted, in ADR, and
skips if the user has typed an entire line. If the user has not yet
typed an entire line, the UUO does not skip and ADR is not changed.
GETLIN TTYUUO 6,
GETLIN ADR
This UUO gets the line characteristics for a teletype line. If
the contents of ADR are less than zero, the line characteristics for
II.D.6-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
your teletype are returned in ADR. If ADR is between 0 and the
maximum legal line number, the line characteristics of the teletype
whose line number is in ADR are returned in ADR. If aDR is greater
than the maximum legal line number, 0 is returned in ADR.
To decode these bits, you need only look at the left half of the
word; the right half is the number of the line that the
characteristecs in the left half are for. These are the meanings of
the bits:
BIT 0
This means that the teletype connected to this line is a III
display console.
BIT 1
This means that this line is the console teletype line (big
deal!).
BIT 2
This means that this line is an ARDS storage-tube display and you
may draw pictures on it.
BIT 3
This means this is a data set data line.
BIT 4
This means this is a data set control line.
BIT 5
This means that this is a half-duplex line.
BIT 6
This means that this is a pseudo-teletype line.
BIT 9
This bit, called PTYWAKE, means that pseudo-teletype input wait
is terminated by teletype also. See SETLIN below.
BIT 11
If you turn this bit on (with a SETLIN UUO described below) it
changes the definition of line mode. This is called "special
II.D.6-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
activation" mode. In this mode, any operation which waits or skips
on the basis of whether the user has typed a complete line will
instead wait or skip on the basis of whether the user has typed a
character which is not a letter or number. Line mode is changed to
"word" mode if this bit is on.
BIT 12
If this bit is on, it means the last character that was typed was
a rubout, and that a backslash will be typed when the next character
typed is not a rubout.
BIT 13
This means the teletype is in "model 37" mode and lower case will
not automatically be changed to upper case. This is the bit that
gets inverted by typing control-F on the teletype (see section
I.B.10).
BIT 14
This means the teletype is in "model 35" mode and the teletype is
assumed to have a hardware tabbing mechanism. Normally, tabs are
converted into the appropriate number of spaces. This is the bit
that is inverted by typing control-P on the teletype (see section
I.B.10).
The model 35 has hardware tabs and form-feeds, but it does not
have internal timing for these characters. The character actually
takes several "character-times" to complete. It is for this reason
that many non-printing characters (deletes, octal 177, to be exact)
are sent after each tab and form-feed to kill time while the carriage
is moving. If you are on a terminal that is capable of printing the
delete as a downarrow, like the III displays and the ARDS are, then
you can tell immediately whether the terminal is in model-35 mode or
not by seeing if there are downarrows (↓) after each tab or
form-feed.
BIT 15
This bit inhibits duplexing of everything except line-feeds after
carriage-returns and dollar signs for alt-modes.
SETLIN TTYUUO 7,
SETLIN ADR
This UUO sets the line characteristics for your teletype from
II.D.6-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
ADR. You are only allowed to change bits 9, 11, and 13 through 16.
All other bits in ADR are ignored.
If the PTYWAKE bit, bit 9, is on, it has the effect that a
teletype character will wake you up even if you are waiting for a
pseudo-teletype character. In this manner, a pseudo-teletype input
UUO can wait for either a teletype or a pseudo-teletype character.
RESCAN TTYUUO 10,
RESCAN
This UUO backs up your teletype input pointer to the previous
line. In this manner, you may read the same line twice, or as many
times as you like. The RPG commands use this UUO to read the command
line over again.
Please note, however, that you can only back up, in general, one
line. It is even possible that the line could be so long that the
RESCAN UUO could not back up to the beginning of it.
CLRBFI TTYUUO 11,
CLRBFI
This UUO clears your input buffer, as if the user had typed a lot
of control-U's. It is intended to clear out any type-ahead the user
may have when a fatal error occurs.
CLRBFO TTYUUO 12,
CLRBFO
This UUO clears your output buffer, as if the user had typed
control-O.
INSKIP TTYUUO 13,
INSKIP
<no characters have been typed>
<there are characters waiting for you>
This UUO tells you if there is anything in your teletype input
II.D.6-5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
buffer. If the user has typed something the UUO will skip. If
nothing has been typed, the UUO will not skip.
INWAIT TTYUUO 14,
INWAIT
This UUO waits until a full line has been typed in. That's all.
It does not get a character for you, it just waits.
There is another usage of this UUO. If the address field is
non-zero, when your job is awakened, the number of characters in the
last line re-edited (III display consoles only) by a <ctrl 1>CR or a
PTYUUO that loads your own line-editor buffer. In other words, if
you give a PTYUUO that outputs a line to your own input buffer and
then do an INWAIT ADR, you will get the new number of characters in
your re-edited line in location ADR. If you are not at a III display
console, or if you did not re-edit a line by typing <ctrl 1>CR or by
doing a PTYUUO to your own line number, the number placed in ADR will
be nonsense.
TTYIOS CALLI 400014
MOVE AC,<teletype name in SIXBIT>
CALL AC,[SIXBIT /TTYIOS/]
This UUO returns you the I-O status bits of the teletype whose
name (logical or physical name) is in the accumulator AC. The status
bits are returned in the accumulator. The meanings of the bits in
the right half are given in section II.C.1. Of the bits in the left
half, these are the interesting ones:
BIT 9
This bit, called TPMON, tells whether the teletype is in monitor
mode or not. If the bit is a one, every line typed will go to the
monitor as if it were a monitor command. This bit is usually turned
off when your job is running, but you can make it stay on by giving a
CSTART or CCONTINUE command. when this bit is on, your program will
not be able to get any input from the teletype, because all the
characters will be going to the monitor's command decoder.
BIT 10
This means control-O has been typed. When this bit is on,
nothing your program outputs to the teletype will be printed. The
only way to clear this bit is to do a teletype input operation of
II.D.6-6
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
some sort. Also, this bit may be turned off by re-initializing (with
an INIT or OPEN) the teletype.
BIT 11
If this bit is on, bit 9 is also on. This means that when the
current type-out is finished, turn bits 9 and 11 off. This bit is
turned on when the monitor is typing a message to the user just
before returning control to the user. When the message is typed out,
the teletype is set to user mode (bit 9 is turned off) and all type
in then goes to the user.
CTLV CALLI 400001
CALL [SIXBIT /CTLV/]
This UUO causes all teletype duplexing by the monitor to cease.
This means that every time the user strikes a key, no letter will be
printed. This is used by the text editor in inter-line alter mode.
This UUO is inverting, in that you get out of this mode by giving the
UUO again. If you get into this mode, there is no single character
you can type to get teletype echoing back. Control-B turns on all
duplexing except for line feeds after carriage-returns. You have to
type control-B and control-S. For this reason, it is a good idea
never to type control-C in an inter-line edit because it is confusing
and sometimes difficult to get back your duplexing.
PTYUUO UUO 711
PTYUUO <function>,ADR
ADR: <pseudo-teletype line number>
<this depends on the function>
This is the marvelous multi-purpose pseudo-teletype UUO. Before
I describe its many wonders in detail, let me talk a little about
pseudo-teletypes.
A pseudo-teletype is an artificial construct within the system to
allow users to have and control more than one job at a time. If you
do output to a pseudo-teletype, it is as if you were sitting at a
teletype typing those characters that you outputted. The
pseudo-teletype reads your characters just like a regular teletype
does. If you send the character "L" followed by a carriage return,
line feed to a pseudo-teletype, it will login a job just as if you
had typed that to a teletype. The pseudo-teletype will then type
II.D.6-7
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
back the duplexing of what you typed (unless you turn off duplexing
with a PTSETL UUO described below) and the usual message the system
puts out when someone logs in. You can (and should) read this
message by reading characters from your pseudo-teletype.
The job which initiates a pseudo-teletype owns it uniquely and no
other job may fiddle with that pseudo-teletype. If you do a
pseudo-teletype UUO with the line number in ADR set to zero, it is as
if the user had typed those characters you output. This means a job
can stop itself by sending control-C to line number zero! This also
means that you may do from a program anything you can do from a
command by sending the command to the monitor by doing a
pseudo-teletype output UUO with the line number set to zero.
Pseudo-teletypes are initialized in model 35 mode and with no
duplexing of line feeds after carriage returns. You may want to
inhibit all duplexing, or you may want the system to put in line
feeds after your carriage returns. All this may be specified by
setting the line characteristics of the pseudo-teletype with a PTSETL
UUO.
A programming hint for pseudo-teletype users: Often, typeouts
from a pseudo-teletype will not be complete. That is, often you have
to do many inputs to get the entire message. For example, to log in
a job, you do one input to get back your duplexing, another input to
get back the monitor printout of the job number, and a third input to
get back the sharp sign (#) the LOGIN program types. The reason this
is so is because certain typeouts from the monitor require that they
be completed entirely before any further typeouts be admitted. One
of these situations is when a teletype goes from a virgin state to an
attached state. Another is when the teletype is handed over from the
monitor to the user, or back. This is why when you give "L" to a
pseudo-teletype, you get the "L" back in one gulp because the
pseudo-teletype goes from virgin to attached state after that. The
"Stanford A-I 3.27" stuff comes back next because after that, the
teletype is handed over to the LOGIN program, so you have to get that
message before you can get the sharp sign (#) from the LOGIN program.
All pseudo-teletype (hereafter referred to as PTY) UUOs expect a
two word block at ADR, even though some of the UUOs only use the
first word. In every PTY UUO, the first word of the two word block
is the PTY line number. This number is unique and is guaranteed to
be different from any line number of any existing teletype.
PTYGET PTYUUO 0,
PTYGET ADR
<none available>
<successful return>
This UUO initializes a PTY and places the line characteristics
II.D.6-8
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
word in ADR. This means that the PTY line number will appear in the
right half of ADR and the line characteristics will appear in the
left half.
The UUO skips if a PTY is available and assigned to you. It does
not skip if there are no PTYs available.
PTYREL PTYUUO 1,
PTYREL ADR
This UUO releases the PTY whose line number is in ADR. This also
kills any jobs you may have initialized through your PTY.
PTIFRE PTYUUO 2,
PTIFRE ADR
This returns to you in ADR+1 the number of free characters left
in the PTY's input buffer, whose line number is in ADR. This number
is the number of characters you may send to that PTY before the job
has to read some. If you use a PTY output UUO that waits and if you
send more characters than this number, you will have to wait while
the program initialized by the PTY reads some characters and makes
room for your output.
PTOCNT PTYUUO 3,
PTOCNT ADR
This puts the number of characters in the PTY output buffer in
ADR+1. This is the number of characters you will get if you do a PTY
input UUO to this PTY.
PTRD1S PTYUUO 4,
PTRD1S ADR
<no character is present>
<successful return>
This UUO is the PTY analog of INCHRS, or TTYUUO 2,. This gets
you one 7-bit character and skips if you got a character. The
II.D.6-9
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
character is placed, right-adjusted, in ADR+1. If there are no
characters to be had, the UUO does not skip and a 0 is placed in
ADR+1.
PTRD1W PTYUUO 5,
PTRD1W ADR
This UUO is the analog of INCHRW. This gets you one 7-bit
character and places it, right-adjusted, in ADR+1. If there is no
character to be had, this UUO waits for one and does not return until
one is available. There is another interesting feature of this
instruction. If you are waiting for a PTY character and a character
is typed on your real teletype, and if the PTYWAKE bit is on in the
line characteristics word (see PTSETL below), this UUO will return
and place a zero in ADR+1. In this manner, you may wait for either
PTY or teletype input by using this one UUO.
PTWR1S PTYUUO 6,
PTWR1S ADR
<character can not be transmitted>
<successful return>
This UUO transmits the 9-bit character that is right adjusted in
ADR+1 to the PTY whose line number is in ADR. If the PTY's input
buffer is full and there is no room for the character, the UUO does
not skip and the character is not transmitted. If there is room, the
character is transmitted and the UUO skips.
PTWR1W PTYUUO 7,
PTWR1W ADR
This is the same as PTWR1S except that if the character can not
be transmitted, the UUO waits until there is room in the buffer, then
transmitts it.
II.D.6-10
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
PTRDS PTYUUO 10,
PTRDS ADR
This takes all the characters waiting in the PTY output buffer
for you and gives them to you as an ASCIZ string in the address found
in ADR+1. You may find out how many characters you will get by doing
a PTOCNT UUO.
You shouldn't take this number too seriously, because between the
time you give this UUO and you get around to reading the characters,
it is quite possible that some more characters may have arrived.
This number is just the minimum number of characters you will
receive.
PTWRS7 PTYUUO 11,
PTWRS7 ADR
This takes the ASCIZ string whose address is in ADR+1 and
transmitts it to the PTY whose line number is in ADR.
PTWRS9 PTYUUO 12,
PTWRS9 ADR
This is the same as PTWRS7 except that the string is not a
standard 7-bit ASCIZ string, but is instead a string of 9-bit
characters terminated by a zero (null) character.
This is important because octal code 003 (β or control-C) does
not mean control-C if you are sending this string to yourself (line
number in ADR set to zero) and you happen to be at a III display
console. The code to stop your job in this case is 600, which takes
nine bits to represent. By the by, 600 acts as control-C to all
PTYs, so if you want to stop a PTY job, you should send it 600 rather
than 003.
PTGETL PTYUUO 13,
PTGETL ADR
II.D.6-11
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
This gets the line characteristics for the PTY whose line number
is in ADR and puts them in ADR+1. For the format of the line
characteristics word, see the GETLIN UUO above, TTYUUO 6,.
PTSETL PTYUUO 14,
PTSETL ADR
This sets the PTY line characteristics from ADR+1. There is
essentially no difference between a PTY line characteristics word and
a TTY line characteristics word. If you set, with a SETLIN UUO, the
400 bit, called PTYWAKE, it causes PTRD1S and PTRD1W to return on TTY
input as well as PTY input.
If you set this bit with a PTSETL UUO to your own teletype (line
0) it is the same as if you did a SETLIN UUO. If you set it on some
other line and initialize a job through the PTY and that job
initializes another job through a PTY, then if it goes into a wait
for input from its PTY, it will be awakened if you send it characters
also. Just like teletype except one level deeper.
PTLOAD PTYUUO 15,
PTLOAD ADR
ADR: 0
<address or byte pointer to string>
This UUO only works if the line number is zero (your own
teletype) and only if you are at a III display console. This UUO
loads your line editor buffer with the string whose address or byte
pointer is in ADR+1 and whose end is defined by the first occurance
of a null or an activation character (carriage-return, line-feed,
etc.). You may then do a line mode teletype input UUO to get your
line back with any corrections the user may have made.
II.D.6-12
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.7 SPECIAL MAGNETIC TAPE UUO
MTAPE UUO 072
MTAPE <channel number>,<function>
This UUO enables the user to do all the things that the magnetic
tape can do that other devices cannot do. you must have INITed or
OPENed a magnetic tape on some channel, and then you may give this
UUO. Exactly what is done depends on the number represented above as
"function". These are the legal functions:
1
This causes the magnetic tape initialized on that channel to be
rewound. No further operations may be done until the tape is at the
load point.
3
This causes an end-of-file mark to be written on the tape.
6
This causes the tape to be advanced one record.
7
This causes the tape to be backspaced one record.
10
This causes the tape to be advanced to the logical (as opposed to
physical) end of tape. This causes a search for two consecutive
end-of-file marks to occur and the tape is left positioned after the
second one.
13
This causes three inches of blank tape to be written. The
purpose of this is to cause a bad spot on the tape to be ignored.
Perfectly blank tape looks like an end-of-record mark to the
controller and is ignored. The monitor automatically writes blank
tape over bad spots on the tape.
16
This causes the tape to be advanced one file. The tape is
positioned after the end-of-file mark that terminates the file.
17
This causes the tape to be backspaced one file. The tape is
positioned before the end-of-file mark at the end of the previous
file.
If you plan to use the magnetic tapes seriously, you should read
II.D.7-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
the additional write-up on them in section II.E.7 before you start
programming.
II.D.8 SPECIAL III DISPLAY UUOs
This part of the manual tells how you may run a iii display
program under the time-sharing system. It does not tell how to
program the display processor. This processor is a separate
stored-program computer and has instructions, jumps, stores, and
arithmetic just like any other computer. For a description of how to
program the display processor, see SAILON number 29 by William
Weiher, entitled "Preliminary Description of the Display Processor".
DPYCLR UUO 701
DPYCLR
This returns your display to its virgin state. It clears any
display program that might be running and resets the page printer to
normal.
PPIOT UUO 702
PPIOT <function>,<arguement>
This is a multi-purpose page printer UUO. Your page printer is
the part of the monitor that puts text information on your screen.
Normally when no display program is running, the page printer is the
only thing that is active and your text is spread over the entire
screen. This UUO allows you to reposition your text to any fraction
of the screen. I shall now describe the various functions this UUO
is capable of:
PPSEL PPIOT 0,
PPSEL <piece of paper number>
There are sixteen logical pieces of paper to which your teletype
output and duplexing is directed. You may select any one of these,
one at a time, as the one where teletype printing goes. This UUO
expects the effective address to be a piece of paper number from 0 (0
II.D.8-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
is the default option) to 17 (octal). This causes all you teletype
printing to go to that piece of paper.
PPACT PPIOT 1,
PPACT <page specifications>
This UUO expects the effective address to be a bit map telling
which pieces of paper are to be displayed. Normally, only page zero
is displayed. By placing a one in bit 18+piece of paper number, you
may turn on a different page. Bit 18 is for piece of paper 0, bit 19
for 1, and so on.
Note that a PPSEL UUO shuts off all pieces of paper other than
the one being selected, so if you want several pieces of paper to
co-exist on the screen after giving a PPSEL UUO, you must give
another PPACT UUO.
DPYPOS PPIOT 2,
DPYPOS Y
This causes the vertical (Y-axis) position of the first line to
be set to Y, where -1000 is the bottom of the screen and +1000 is the
top of the screen. DPYCLR resets this back to +1000.
This UUO and the next (DPYPOS and DPYSIZ) refer only to the
currently selected piece of paper. This can have some neat effects,
because this means that each piece of paper is controlled
independantly so that conceivably, you could have all sixteen pieces
of paper in sixteen different non-overlapping areas of the screen.
DPYSIZ PPIOT 3,
DPYSIZ X*1000+Y
This UUO communicates two pieces of information to the system:
The number of glitches (to be defined below), X in bits 18-26 of the
address part of this UUO, and the number of lines on each glitch, Y
in bits 27-35 of the address part of the UUO. Now let me explain
what a glitch is. When you type over a certain number of lines and
your typing threatens to run off the bottom of the page, the screen
jumps up some number of lines. This is called a glitch. The number
of lines up it jumps may be set by giving this UUO and changing Y
from its normal value of 4 to something else. The total number of
II.D.8-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
lines on the page depends on the number of lines in each glitch (Y)
and on the number of glitches that are printed (X). You may change
the total number of glitches on the screen by changing X from its
normal value of 5 to something else. The total (maximum) number of
lines on the page is X*Y.
PPREL PPIOT 4,
PPREL <piece of paper number>
This essentially flushes the piece of paper whose number is the
effective address of the UUO. It dissapears from the screen if it
was being displayed and all text associated with it is erased. The
physical storage in the monitor associated with that piece of paper
is released. If the piece of paper you are releasing is currently
selected, a PPSEL to piece of paper zero is done.
UPGIOT UUO 703
UPGIOT <piece of glass number>,ADR
ADR: <address of display program>
<length of display program in words>
This causes your display program to be run. The program should
be written with an extra word at the beginning, because the monitor
uses that word to interface your program with the rest of the display
programs that are running. Your program is essentially a subroutine
called with the JSR instruction mentioned below.
The only instruction that is illegal in a display program is the
JMS instruction. To do the function of a JMS, there are two new
instructions not written up in SAILON number 29. These are JSR,
opcode 24, and SAVE, opcode 64. The JSR instruction deposits the
display program counter (PC) word in the address, then jumps to the
address plus one. The SAVE instruction deposits the PC word in the
address.
You may have up to 16 different and independant pieces of glass
(display programs) running at once. Let it be known that RAID uses
piece of glass 17 (octal) so that all users are asked to refrain from
using this piece if possible to avoid the obvious conflict.
II.D.8-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
PGIOT UUO 715
PGIOT <function>,<arguement>
This is the multi-purpose piece of glass UUO. Its various
features are described below:
PGSEL PGIOT 0,
PGSEL <piece of glass number>
This UUO expects the effective address number to be the octal
number 0 to 17. This causes the piece of glass whose number is the
effective address to be selected. This means that the next two UUOs
refer to the currently selected piece of glass and are illegal if no
piece of glass is selected.
PGACT PGIOT 1,
PGACT <piece of glass specification>
This is the piece-of-glass analog of PPACT. A zero in bit
position 18-<piece of glass number> causes that piece of glass to be
invisible. A one in said position causes the piece of glass to
become visible. The display code for the piece of glass still exists
when it is invisible and may be reactivated at any time.
PGCLR PGIOT 2,
PGCLR
This causes all your pieces of glass to be cleared, but does not
affect your page printer at all. If you have set your typeout to
some strange place on the screen, this UUO will not affect that
position.
II.D.8-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
UPGMVM UUO 714
UPGMVM AC,ADR
This UUO is illegal unless a piece of glass has been selected by
a PGSEL UUO, in which case, it updates the display program of that
piece of glass by replacing the word that would have been at the
location ADR which must have been in the area in core that you
specified when you did the UPGIOT to this piece of glass. In other
words, you could update your display program by doing a MOVEM AC,ADR
and another UPGIOT, or you can give this UUO with exactly the same
effective address as you would use if you were doing a MOVEM. This
is a MOVEM into your display program, which is already in progress.
UPGMVE UUO 713
UPGMVE AC,ADR
This is the MOVE analog of the last UUO. This picks up a word in
your display program specified by ADR and places it in accumulator
AC.
II.D.9 SPECIAL LIBRASCOPE UUOs
UFBCLR CALLI 400012
CALL [SIXBIT /UFBCLR/]
This UUO releases any and all Librascope disk bands you may have.
UFBGET CALLI 400010
MOVE AC,<number of the band you want>
CALL AC,[SIXBIT /UFBGET/]
<no bands available>
This gets you one Librascope band, which is 76*1024 words long
(both 76 and 1024 are decimal numbers). If there is a band
available, the UUO takes the skip return. If no more bands are
available, the UUO does not skip. The band number you give is the
II.D.9-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
number that you use to identify the particular band. You may have up
to 40 bands, so the number may be from 0 to 37.
UFBGIV CALLI 400011
MOVE AC,<number of the band you wish to release>
CALL AC,[SIXBIT /UFBGIV/]
This releases the band whose number is in the accumulator. It
does not affect any other bands you might have.
FBREAD UUO 706
MOVE AC,<number of band>
FBREAD AC,ADR
<error return>
ADR: <address you want the data to go>
<number of words to be transferred>
<sector address of beginning of transfer>
This UUO causes the band identified by the number in the
accumulator AC to be read into the address specified by the first
word of the 3-word block at ADR. The second word at ADR tells how
many words are to be transferred. The third word is the number of
the 32 word sector that is to be the first sector transferred. On
each band, there are 2432 (decimal) sectors of 32 (decimal) words
each. The sector numbers run from 0 to 2431. If you ask for a
sector greater then 2431 or less than zero, you get an error message.
If there are errors in reading the disk, the error return will be
taken and that band will be discarded, so that any further attempts
to read or write it will fail. You must then release that band and
get another one. You may use the same band number and the system
will assign you another band.
If you have not given a UFBGET UUO for that band number, the
error return will be taken.
II.D.9-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
FBWRT UUO 707
MOVE AC,<band number>
FBWRT AC,ADR
<error return>
ADR: <address of data>
<number of words of data>
<beginning sector number>
This UUO causes all or part of a band to be written out. The
address in core of the data you wish to write must be at ADR. The
count of the number of words to be transferred must be in ADR+1. If
this count is not a multiple of 32 (decimal), then the remainder of
the 32 word sector at the end of the transfer will be filled with
garbage. You may not write off the end of a band, that is, you may
not give a transfer which transfers data beyond sector 2431.
The error return is taken if the band you are attempting to write
on has been judged as evil and discarded. You must release the band
and claim it again. You get the error return if you try to write on
a band that you haven't claimed.
You may not read a band that you have not written yet and expect
to get anything but garbage.
II.D.10 SPECIAL DECTAPE UUO
UTPCLR CALLI 13
CALL <channel number>,[SIXBIT /UTPCLR/]
This UUO causes the dectape initialized on the channel number to
be cleared. This UUO is a no-op for any devices other than the
dectape.
If you plan to use dectapes seriously you should read the section
on them, section II.E.3, plus you should read the special provisions
mentioned in sections II.D.3 and II.D.11 before you attempt to
program them.
II.D.10-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.11 RANDOM ACCESS PROVISIONS
Files on the disk and on dectape are essentially serial files.
You start reading them at the beginning and each successive INPUT UUO
gets you the next part of the file. This may well be inconvenient
for some purposes, so there are a series of random-access UUOs which
allow the user to select which 200-word block he wishes to read or
write. There is a fundemental difference between the operation of
this UUO on the disk and on dectape. On the disk, your blocks are
numbered consecutivly from start to finish. The first block of a
file on the disk is always block number 1. The second block is block
number 2, and so on. On the dectape, the blocks are physical block
numbers, so the first block of a file is not necessarily number 1.
You get the number of the first block of a file in the right half of
ADR+1 when you do a LOOKUP on a dectape file. The successive block
numbers are stored in the left half of the first word of each block.
The right half of the first word of each block is the count of the
number of words of data in that block. A block number of 0 on the
dectape means there are no more blocks in the file.
USETI UUO 074
USETI <channel number>,<block number>
This UUO sets the next block number to be inputted to the address
portion of the UUO. Every successive INPUT operation will come from
that block until another USETI is given.
USETO UUO 075
USETO <channel number>,<block number>
This UUO sets the next block number to be outputted to the
address portion of the UUO. Every successive OUTPUT operation will
go to that block until another USETO is given.
UGETF UUO 073
UGETF <channel number>,ADR
This UUO gets the number of the next free block you may write on
and puts it in the right half of ADR. The most common way of doing
this is to have a USETO instruction at ADR and the UGETF UUO puts the
II.D.11-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
block number directly into the USETO instruction.
II.D.11-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.12 CHECKING IO STATUS
GETSTS UUO 062
GETSTS <channel number>,ADR
When this UUO is given, the status bits (see section II.C.1) for
the device initialized on that channel number are placed in the word
whose address is ADR.
STATZ UUO 063
STATZ <channel number>,BITS
<one or more of the bits in BITS is on>
<all of the bits in BITS are off>
The purpose of this UUO is to allow you to test certain bits in
the IO status word without having to do a GETSTS and test them
yourself. You put the bits you want to test in the address portion
of the UUO (denoted above as BITS) and give the UUO. It will skip if
all the bits you said to test are zero and it will not skip
otherwise.
STATO UUO 061
STATO <channel number>,BITS
<all the bits in BITS are off>
<one or more of the bits in BITS is on>
This is just like STATZ except that it skips if any of the tested
bits are on and does not skip if they are all off.
SETSTS UUO 060
SETSTS <channel number>,ADR
This UUO replaces the right half of the IO status word with the
right half of the contents of ADR. With this UUO, you may change
from buffered mode to dump mode any time you wish. You may also use
it to turn off the end-of-tape bit, or any error bit.
II.D.12-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.13 UUOs TO GET INFORMATION
DATE CALLI 14
CALL AC,[SIXBIT /DATE/]
This UUO returns the date in the accumulator AC in system date
format. This is ((year-1964)*12+month-1)*31+day-1. You may separate
out the individual parts by dividing. If you divide by 31 (decimal)
and add one to the remainder, the remainder is then the day number.
If you then divide the quotient by 12 and add one to the new
remainder, the new remainder is then the month number. If you take
the resulting quotient and add 1964, the result is the number of the
year.
TIMER CALLI 22
CALL AC,[SIXBIT /TIMER/]
This UUO returns the time of day in 60ths of a second since
midnight in the accumulator AC. You may turn this number into
seconds since midnight by dividing it by 60 (decimal).
MSTIME CALLI 23
CALL AC,[SIXBIT /MSTIME/]
This UUO gets you the time of day in milliseconds since midnight
in the accumulator AC. The monitor gets this number by taking the
time since midnight in 60ths of a second and multiplying it by the
appropriate constant.
RUNTIM CALLI 27
MOVE AC,<number of job or 0>
CALL AC,[SIXBIT /RUNTIM/]
This returns the total compute time since login of the job whose
number is in accumulator AC. If the accumulator is zero, the compute
time for your job will be returned. This time is in milliseconds.
This is the time that the job has actually spent (system overhead is
not accurately subtracted off, however) computing. This means that
time waiting for a key to be typed is not counted.
II.D.13-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
PJOB CALLI 30
CALL AC,[SIXBIT /PJOB/]
This UUO returns your job number, right-adjusted, in accumulator
AC.
GETPPN CALLI 24
MOVE AC,<number of job>
CALL AC,[SIXBIT /GETPPN/]
This UUO returns the project-programmer name of the job whose
number is in AC. If that number is zero, it returns your
project-programmer name.
Although it is rare that this happens, I must include this fact
for completeness. If you are writing a new LOGOUT program, you must
know that when a program is running as LOGIN or LOGOUT, this UUO will
skip if there is more than one person logged in under that
project-programmer name. At no time in the normal course of events
will it skip, just when it is imbedded in the LOGIN or LOGOUT
program.
SWITCH CALLI 20
CALL AC,[SIXBIT /SWITCH/]
This causes the 36-bit switch register on the PDP-10 console to
be placed in the accumulator AC.
DEVCHR CALLI 4
MOVE AC,<device name in SIXBIT>
CALL AC,[SIXBIT /DEVCHR/]
This causes the device characteristics word of the device whose
logical or physical name was in accumulator AC to be stored in
accumulator AC. If the device is unknown to the system, a 0 is
returned. The bits in the left half of this word may be interpreted
as follows:
II.D.13-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
BIT 0
This means that the directory (if this is a dectape) is in core.
This bit will always be 0 on devices that are not dectapes.
BIT 1
This means this device is the disk.
BIT 2
This means this device is the user disk pack (UDP).
BIT 3
This says this device is the line printer.
BIT 4
If this device is a teletype, this means this teletype is
attached to a job.
BIT 5
If this device is a teletype, this means this teletype is in use
at this time.
BIT 6
This means this device is a TV camera.
BIT 7
This means this device is a DEC type 30 display. We have no such
animal at Stanford.
BIT 8
This means this device has a long dispatch table, which means
that it accepts UUOs other than INPUT and OUTPUT, like MTAPE, USETO,
LOOKUP, and all those.
BIT 9
Means this device is a paper tape punch.
BIT 10
Means this device is a paper tape reader.
BIT 11
This device is a dectape.
BIT 12
If this bit is a 1, it means this device is available to the
program that gave the DEVCHR UUO if it wants it.
BIT 13
This device is a magnetic tape.
II.D.13-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
BIT 14
This device is a teletype.
BIT 15
This device has a directory. At Stanford, this means this device
must be the disk or a dectape.
BIT 16
Means this device can do input.
BIT 17
Means this device can do output.
BIT 18
Means this device has been assigned by the ASSIGN command.
BIT 19
Means some program has done an INIT or OPEN on this device and is
using it. If bit 12 is on, indicating the device is available, it
means that either both these bits are off (bits 18 and 19) or the
program doing the DEVCHR UUO has the device.
PEEK CALLI 33
MOVE AC,<address you want to look at>
CALL AC,[SIXBIT /PEEK/]
This UUO fetches the word specified by the absolute address
contained in accumulator AC and places it in the accumulator. In
this manner, you may look at words in the monitor itself. To help
you find certain tables in the monitor, locations 210 to 236 in the
monitor contain the addresses of useful tables. This is so when the
monitor is reassembled and the tables are in different places, you
can still find their addresses by looking down in 210 to 236. These
are some of the useful things you can see:
210
This contains the address of JBTSTS, the job status table. This
address plus the job number contains the job's status word. Some of
the important bits in this word are as follows:
BIT 0
Tells whether the job is runnable. It may be in a wait state of
some kind. This bit gets shut off by typing control-C, or giving the
II.D.13-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
EXIT UUO, or hitting an error of some sort.
BIT 1
Means the job is waiting to be swapped in to service a command.
BIT 2
Means LOGIN or LOGOUT is running and control-C may not be typed
at this time.
BIT 3
This indicates that a job number has been assigned and printed
out on the teletype.
BIT 4
This means the job has terminated with an error and the user may
not continue, he must restart the program or call in another program.
BIT 5
This means the job is successfully logged in. This is not set
until the LOGIN program is about to terminate.
BIT 6
This means the job is currently being shuffled in core.
BIT 7
This means the job is swapped out.
211
This contains the address of PRJPRG, the project-programmer name
table. This location plus the job number contains the
project-programmer name of that job.
212
The contents of this location is the address of the swapper's
data table, called JBTSWP. In this address plus the job number may
be found a word whose left half is the band number used to swap this
job and the right half is divided into 9-bit bytes. Bits 18-26
contain an integer that is the size of the job as it appears on the
disk. Bits 27-35 contain an integer that is the size of the job (in
II.D.13-5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
number of 1K blocks) as it will appear when it is swapped in.
213
This contains the address of SPWGO, which is a table of the
addresses of all the PDP-10 spacewar jobs that are currently active.
This address plus the job number contains in the right half, the
address in user's core of his spacewar module, and in the left half
in bits 14-17 has the number of 60ths of a second between spacewar
startups, and in bits 10-13 has the number of 60ths of a second to
the next time the job is started up.
214
This has the address of TTIME. This location plus the job number
gives the total run time in 60ths of a second that that job has
accumulated since it has logged in. The time for job 0 is the time
the machine has spent idle since the system was reloaded.
215
This has the address of UPTIME, which contains the time in 60ths
of a second since the last system reload.
216
CORMAX contains the largest size a program can be and still fit
into core.
217
The content of this address is the address of DEVLST. The left
half of DEVLST is the address of the first device data block. The
device data block contains all sorts of good things. This is what it
is:
WORD 0 - DEVNAM
This word has the device's physical name in sixbit.
WORD 1 - DEVCHR
Bits 0-5 contain the number of the job this device belongs to, 0
if unused. Bits 6-11 contains the hung time count down. Bits 12-17
contain the hung time in seconds. Bits 18-23 contain the unit number
for multiple unit devices like dectapes and magnetic tapes. Bits
24-35 contain the size in words of the buffer this device uses.
WORD 2 - DEVIOS
This is the device's IO status word.
II.D.13-6
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
WORD 3 - DEVSER
The left half of this word is the address of the next device data
block in the chain, or zero if this is the last device. The right
half contains the address in the monitor of this device's UUO
dispatch table.
WORD 4 - DEVMOD
This is the word you get from a DEVCHR UUO.
WORD 5 - DEVLOG
This contains the device's logical name in sixbit, if any.
WORD 11 - DEVFIL
For directory devices like the disk and dectapes, this word
contains the file name in sixbit that is currently open, or zero if
no file is open.
WORD 12 - DEVEXT
This word contains the file name extension.
WORD 13 - DEVPPN
This word contains the project-programmer name of the file.
222
This contains the highest job number a job may have.
223
This is a table called JBTADR. The contents of the address
contained in 223 plus the job number is the protection-relocation
word for that job, and zero if it is swapped out. The protection is
in the left half.
225
This contains the address of JOBNAM, which is a list of the
names, in sixbit, of the jobs that are currently running.
226
This has the address of JOB, which contains the number of the job
that is currently running.
227
This contains the address of CONFIG, which is an ASCIZ string
that states the title of the system.
230
This contains the address of SP2GO, which is just like SPWGO for
II.D.13-7
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
the PDP-6.
231
Here lies the address of JOBQUE, which when added to a job number
gives the address of the word that contains the negative of the queue
the job is currently in.
235
This contains the address of QNAMS, which is a list of the ASCII
print names of each of the queues.
236
This has the address of JBTLIN, which when added to a job number
gives the address of a word which is the line number of the teletype
that job is attached to, or -1 if the job is detached.
PNAME CALLI 400007
MOVE AC,<device name in SIXBIT>
CALL AC,[SIXBIT /PNAME/]
<error return>
This routine takes the logical or physical device name in the
accumulator AC, returns the physical name of the device in the
accumulator, and skips the next instruction. If the device does not
exist, the UUO does not skip and the accumulator is unchanged. This
is the only way you can find out a device's physical name from its
logical name.
JBTSTS CALLI 400013
CALL AC,[SIXBIT /JBTSTS/]
This UUO gets you the job status word for the job whose number is
in accumulator AC. The explaination for the bits in the job status
word may be found above under the PEEK UUO. This one UUO may be
simulated by two PEEK UUOs. With this UUO, you may find out if
another job is running, swapped out, or waiting just by testing
various bits in the job status word.
II.D.13-8
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
CHNSTS UUO 716
CHNSTS <channel number>,ADR
This UUO places the use bits for the IO channel whose number is
in the accumulator field of this instruction in the location
specified by ADR. These bits may be decoded as follows:
BIT 18 - INITB
This bit is on if the channel has been opened with an INIT or an
OPEN and a RELEAS has not been given yet.
BIT 19 - IBUFB
This bit is turned on if the INIT or OPEN which initialized this
channel specified an input buffer header address.
BIT 20 - OBUFB
If an output buffer header address was specified by the INIT or
OPEN which initialized this channel, this bit will be on.
BIT 21 - LOOKB
This bit is on if any kind of LOOKUP, successful or not, has been
done on this channel.
BIT 22 - ENTRB
This bit is on if any kind of ENTER, successful or not, has been
done on this channel.
BIT 23 - INPB
If an INPUT or an IN UUO has been done on this channel, this bit
will be on.
BIT 24 - OUTPB
This bit is turned on when an OUTPUT or an OUT UUO are done.
BIT 25 - ICLOSB
When the input side of an IO channel is closed, this bit is
turned on.
BIT 26 - OCLOSB
This bit will be on if the output side is closed. Both this bit
and the previous bit will be on if an unspecified CLOSE is given, or
if both sides have been explicitly closed.
BIT 27 - INBFB
This bit is turned on when a input buffer ring is set up for this
II.D.13-9
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
channel.
BIT 28 - OUTBFB
This bit is turned on when an output buffer ring is set up for
this channel.
BUFLEN CALLI 400042
MOVE AC,[SIXBIT /<device name>/]
CALL AC,[SIXBIT /BUFLEN/]
This UUO returns the length of the data portion, plus one, of the
buffer that would be set up if you did an INIT and then an INBUF or
OUTBUF for the device whose name in SIXBIT is moved into the
accumulator AC above. A zero is returned if the device is not
recognized. To get the true number of words that the entire buffer
will take, you must add 2 to the number you get back.
This is exactly the number you may use in a UINBF or UOUTBF UUO
to set up a buffer of the standard length for this device.
NAMEIN CALLI 400043
MOVE AC,[SIXBIT /<job name>/]
CALL AC,[SIXBIT /NAMEIN/]
<error return - code in AC>
One may use this UUO to determine if a particular word is
currently the name of one of the jobs on the system. If the skip
return is taken, that word is the name of one and only one job on the
machine. If the error return is taken, the error code may be found
in the accumulator AC. Code 1 means that word is not the name of any
job. Code 3 means that there is more than one job with that name.
II.D.13-10
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.14 SPACEWAR MODE
One of the important points in a time-sharing system is that
users' requests for time are scheduled. As a user uses more and more
time, his priority goes down and he gets larger and larger time
slices. Completely invisible to the user, his program gets shut off
periodically to allow other users to run. This means that no user
gets continuous service, but they all get interrupted and shut off
periodically. There exist needs for perfectly regular service. I
mean if you are running the hydraulic arm, you can't afford to be
shut down for any time at all or the arm will wilt! It is for this
reason that we have a mode of operation on this system that
guarantees perfectly (almost!) regular service. This is called
spacewar mode.
Spacewar mode is essentially a parallel process. You start up a
spacewar job and it runs independently from your main job. When you
initiate a spacewar job, you specify a number of 60ths of a second
between startups. Your spacewar job will be started from the
beginning after that amount of time. While you have a spacewar
module active, your job is locked into core and may not be swapped
out. If there are a lot of people on the machine, this may cause a
noticable degradation of system performance.
Each time your spacewar job is started up, the monitor loads up
several accumulators with important data. You get the processor
number you are running on, your protection-relocation word, some
other things and a warning flag if the monitor knows your job will
not be activated for a while. The only way this can happen is if
your job has to be shuffled (relocated to a different place in core)
or swapped out (only if you give a CORE UUO). The accumulator
assignments are as follows:
1
The value of the spacewar buttons is placed in this accumulator.
2
Your current protection-relocation constant is stored in
accumulator 2.
3
This is the warning accumulator. It is zero normally and set to
-1 if this is the last time your spacewar job will be run for a
while. When you return, this accumulator contains the number of
60ths of a second that your spacewar job was suspended.
4
The number of the processor you are running on is kept here. It
is 1 for the PDP-10 and 2 for the PDP-6.
5
II.D.14-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
This cell is normally zero and is set to -1 if the other
processor, the one this spacewar module is not running on, is dead.
6
You get the job status word (JBTSTS, see PEEK UUO above) for your
main job in this accumulator. If the RUN bit (bit 0) of the job
status word is a zero, you know the main job has exited or typed
control-C, but in any case is not running.
If your spacewar job does an illegal memory reference, gets a
push-down overflow, or a non-existant memory reference, the message
"SPACEWAR LOSSAGE" will be typed and the spacewar job will be killed.
If you try to initiate a spacewar job when one is already running,
you will get an error message. If you attempt to start up a spacewar
job with the time between startups set to 0, you get an error
message. If you attempt to start a spacewar job on the PDP-6 when
the PDP-6 is not running, you get an error message.
Spacewar jobs are run in what is called IOT-USER mode. In this
mode, operation codes 700 and above are treated as machine IO
instructions (CONOs and DATAOs and stuff) rather than UUOs. This
means you can exercize real-time control over IO devices if you are
sure your usage will not conflict with the system's usage of these
devices.
Your spacewar job is started up every so many 60ths of a second
and is allowed to run until it signifies it is ready to terminate
this run by giving a CALL or a HALT. If your spacewar job runs
longer that 15 milliseconds each time it is started up, it may well
conflict with the monitor and slow down the system.
If your spacewar job is running on the PDP-10, you are allowed to
do III display UUOs (see section II.D.8) if you get yourself out of
IOT-USeR mode.
SPCWAR UUO 043
SPCWAR N,ADR
This UUO initiates a spacewar job on the PDP-6. The job will be
started at ADR every N 60ths of a second with the above explained
accumulators loaded up.
Doing a RESET UUO will kill your spacewar job but will also kill
all your IO. Doing a SPCwAR UUO with ADR=636367 will terminate all
your spacewar jobs without affecting anything else.
II.D.14-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
SPCWAR CALLI 400000
CALL AC,[SIXBIT /SPCWAR/]
This reads the status of the spacewar buttons into accumulator
AC. This is the same as you would get in accumulator 1 in a spacewar
job.
SPCWGO CALLI 400003
CALL AC,[SIXBIT /SPCWGO/]
This is the multi-purpose spacewar UUO. With this UUO, you may
initiate a spacewar job on either processor or both processors at
once. All the data about the spacewar job you are going to initiate
is taken from the accumulator AC. In the right half of the
accumulator is the starting address of the spacewar module. In the
left half in bits 14-17 is the time in 60ths of a second between
spacewar job startups. Bit 0 means you wish this job to be run on
the PDP-10. Bit 1 means you wish this spacewar job to be run on the
PDP-6. If both bits are 0, the job is run on the PDP-6. If both
bits are 1, the job is run on both processors. This means that your
code must have been written with that in mind or the chances are that
it will not work.
II.D.14-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.15 SECOND PROTECTION-RELOCATION REGISTER
On the PDP-10 with the KT10A option, such as may be found at
Stanford, a program (core image) may be split into two discontiguous
parts. The first part goes from user address zero to the number in
JOBREL, called the job's protection constant. The second part, if
one exists, starts at user address 400000 and goes up to 400000 plus
the protection constant of the second part, which can not be found in
the job data area like the protection constant of the first part can.
The second part is called the "high segment" or "second segment"
and has its own set of UUOs to create and manipulate high segments.
The high segment is useful if several jobs wish to share pure code,
the pure code may be put in the high segment and write-protected and
as many lower segments as wished may attach to the high segment,
provided it is not protected from the lower segments desiring linkup.
Another common use of the high segment is to store programs up
there which need a common data area. Since high segments may be
loaded up with a program and then detached, one might create many
programs and put them all in the high segment and attach them one at
a time to the lower segment which has the common data area.
An upper segment may execute code only when it is attached to a
lower. When it is detached, it is entirely disconnected from the
master job and subject to swap-out at any time.
Currently, no IO may be done to or from the upper segment, but
this will change in the not too far distant future.
The high segments have a protection scheme like that used on the
disk. As a matter of fact, the protection of a segment is set to the
protection of the lower segment when the segment is created, so the
protection of upper segments is usually 005, meaning it is write
protected from people outside the project that this program lives in.
You may change protection with the SETPRO UUO if you are permitted to
change the segment's protection.
REMAP CALLI 37
MOVEI AC,<highest address in lower>
CALL AC,[SIXBIT /REMAP/]
<error return>
This UUO causes a core image to be broken immediately above the
word whose address is in the accumulator AC when the UUO is given.
This address had better end in 1777 (i.e., this had better be on a 1K
boundary) because the monitor ORs in 1777 to this address and uses
the result as the highest word in the lower segment. The part above
the breaking point becomes the high segment and can be found at
location 400000 and above. The new size of the lower segment is the
number in the accumulator AC, ORed with 1777 and plus one. If the
sign bit of the accumulator AC is on, the high segment is set as
write-protected. This UUO attempts to do an automatic LINKUP (see
II.D.15-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
LINKUP UUO below) if the upper segment is write protected. The REMAP
UUO is done automatically when a SAVEd 2-segment core image is called
in again by a GET, RUN, or R command, or a SWAP UUO.
If there are no more job numbers left to create a high segment
under, or if there is something illegal in your specifications, the
error return will be taken.
SETUWP CALLI 36
MOVE AC,<0 for unprotect, ≠0 for protect>
CALL AC,[SIXBIT /SETUWP/]
<protection violation>
This UUO may be used to write-protect or unprotect your high
segment. If you have no high segment, you always get the successful
return. If you are not allowed to fiddle with this segment, like if
it is protected from you, then you get the error return.
CORE2 CALLI 400015
MOVE AC,<highest upper segment address desired>
CALL AC,[SIXBIT /CORE2/]
<not available or protection violation>
This UUO is capable of making and killing high segments. If you
give this UUO with accumulator AC set to zero, any high segment you
may have will be killed, unless it is protected. If you do not
already have a high segment and give this UUO with a non-zero
accumulator AC, a high segment consisting of that many words will be
created for you.
This UUO, like the CORE UUO (section II.D.17), returns the total
number of 1K blocks remaining in the accumulator AC, so do not expect
it to return with the same thing you called the UUO with.
ATTSEG CALLI 400016
MOVE AC,<job number or job name>
CALL AC,[SIXBIT /ATTSEG/]
<error - error code in AC>
This UUO is used to attach an already existant upper segment to a
lower that doesn't already have one. You put the job number or the
job name in SIXBIT of the high segment to which you wish to attach in
accumulator AC. There are five possible error codes that may be
returned in the right half of accumulator AC:
II.D.15-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
0
This means a protection violation has occured and you are not
allowed to attach to this high segment.
1
This occurs when you give a job name in sixbit and there exists
more than one high segment with that job name. The job number of the
first one is returned to you in the left half of the accumulator.
2
You get this error if the job number you specify is not the job
number of a high segment.
3
This error code means the job name you have given does not exist.
4
This error is given if you do this UUO when you already have a
high segment.
DETSEG CALLI 400017
CALL [SIXBIT /DETSEG/]
This UUO detaches your upper segment.
SEGNUM CALLI 400021
CALL AC,[SIXBIT /SEGNUM/]
This UUO puts the number of your high segment in the accumulator
AC. If you have no high segment, a zero is stored in the
accumulator.
SEGSIZ CALLI 400022
CALL AC,[SIXBIT /SEGSIZ/]
This UUO puts the number of words, minus one, that represents the
length of your upper segment in the accumulator AC. If you have no
upper segment, a zero is returned.
II.D.15-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
LINKUP CALLI 400023
CALL [SIXBIT /LINKUP/]
<error return>
This UUO causes an attempt to be made to find an already existant
upper segment with the same job name, date of creation, and other
important credentials as your job has. If such an upper segment is
found, and if it is write-protected, it is attached to your job.
This is done automatically on the REMAP UUO. If there is no such
upper segment, you get the error return.
Just to clarify things, the UUO does not look out on the disk or
on any bulk storage devices except maybe the swapping disk for this
upper segment. It tries to find a job whose upper segment is the one
you want.
POINTS UUO 712
POINTS ADR
ADR: <table at least 25 locations long>
This UUO puts a list of the job numbers, including your own,
which refer to your upper segment in ADR and succeeding locations.
The list is terminated with a zero. Your list must be as long as the
maximum number of jobs which can occur plus one, which makes 25.
SETPRO CALLI 400020
MOVE AC,<0-8 new protection key; 30-35 segment number>
CALL AC,[SIXBIT /SETPRO/]
<error return>
This UUO allows you to change the protection key of any
non-protected segment to whatever you wish. If bits 30-35 of the
accumulator AC are zero, it refers to your upper segment. If a
protection violation occurs, the error return is taken.
SETNM2 CALLI 400036
MOVE AC,<name, in SIXBIT, you wish your upper to have>
CALL AC,[SIXBIT /SETNM2/]
This allows you to change the name of your upper segment so
II.D.15-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
LINKUP can work right. If you have no upper segment, this UUO has no
effect. If you are not permitted to change the name, the error
return is taken.
If the upper is successfully named, the monitor then scans the
list of job names currently on the system. If there exists another
high segment with the same name, its job number is returned in the
accumulator AC, otherwise, the accumulator is unchanged.
SEGNAM CALLI 400037
CALL AC,[SIXBIT /SEGNAM/]
This returns the name, in SIXBIT, of your upper segment to you in
accumulator AC.
II.D.16 USER INTERRUPT SYSTEM
Before I describe the UUOs used to control the interrupt system,
let me first describe how it works. You initialize the system by
"enabling" yourself for some interrupts. When you enable an
interrupt, this just means that you will permit an interrupt of some
sort to occur, the exact sort depending on the exact bits you give
the system when you enable the interrupts. When an interrupt occurs,
your job is stopped wherever it is and your interrupt-level module is
started. When this occurs, the PC at the time of the interrupt is
placed in JOBTPC in your job data area and your program is started at
the address found in JOBAPR. The exact bits which caused the
interrupt you are currently processing may be found in JOBCNI. When
your interrupt-level module is started, there are several things that
distinguish it from your regular (user-level) job. First off, you
are in IOT-USER mode, which means that UUOs with opcodes over 700 are
not UUOs any more, but are instead CONOs and DATAOs and other IO
instructions. You may do UUOs over 700 by getting out of IOT-USER
mode which may be done with a JRSTF. The second difference between
an interrupt-level job and your regular job is that it is at
interrupt-level (obviously!). This means that it is allowed to do
UUOs as long as they do not result in the job being rescheduled.
This means you cannot do system IO UUOs. You may do a teletype UUO
only if you are assured that it does not result in your being placed
in a wait state. Your interrupt-level module gets one-tenth of a
second to run, after which if it has not dismissed itself, an error
message is generated. You get out of interrupt level in one of two
ways. The most common way is to dismiss the module with a DISMIS
UUO. This causes your interrupt-level module to be terminated, the
interrupt which started it to be cleared, and your regular job will
continue as if nothing had happened, unless you deliberately altered
II.D.16-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
it. The other way to get back to user-level is to debreak rather
than dismis. This has the effect of replacing your user-level
program with your interrupt-level program, or equivalently, this has
the effect of causing your interrupt-level program to become your
user-level program. You can still cause your user-level program to
continue after debreaking because you are given the PC word and the
accumulators. If you debreak then decide to continue your user-level
program, you should get back to your program by doing a JRSTF so as
to restore the program's running flags. If you don't do this, your
user-level program will end up in IOT-USER mode which may be
disasterous.
After you debreak, you are the user-level program and you are
again allowed to do any legal UUO, but you are still in IOT-USER mode
most likely. This description is actually a bit misleading. To
debreak, you do not just give one UUO and there you are, in
actuallity, you must give two separate UUOs. You must first do a
UWAIT UUO, which gets you back the guaranteed true PC and
accumulators of your user-level job. At this point, you are still at
interrupt level, so you will want to save away this PC and these
accumulators and then do a DEBREAK UUO which takes you back to
user-level. The reason this is done this way is because between the
time you do a DEBREAK UUO and the time your program actually gets run
again, another interrupt might occur and there is then an ambiguity
as to which PC is in order, the PC of the user-level job, or the PC
of the interrupt-level job that is debreaking? To eliminate the
ambiguity, I require that you do two UUOs so that when you debreak,
your one and only PC is the PC of the interrupt-level job that is
debreaking and hopefully you have carefully saved away the user-level
PC and accumulators so that this situation is not disasterous. You
may simplify things greatly if you disable further interrupts before
you debreak.
When your interrupt-level module is started up, several
accumulators are set up for you:
AC 1
The status of the spacewar buttons is placed in this accumulator.
AC 2
Your protection-relocation word for your lower segment as an
absolute memory address is placed in accumulator 2.
AC 3
This accumulator is set to -1 if this is the last interrupt
before your job gets shuffled or swapped.
AC 4
The number of the processor this module is being run on is placed
in this accumulator, 1 for the PDP-10, 2 for the PDP-6.
II.D.16-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
AC 5
This accumulator is normally zero, but is set to -1 if the other
processor, not the one you are running on, is dead.
AC 6
Your job status word (JBTSTS) is placed in this accumulator. To
decode the bits in this word, see section II.D.13.
Now I shall describe the UUOs themselves in detail:
INTENB CALLI 400025
MOVE AC,<interrupt bits>
CALL AC,[SIXBIT /INTENB/]
This UUO enables your job for the interrupts specified by the
bits in the accumulator AC. This replaces all previous enablings.
If there is an interrupt pending, it will interrupt immediately when
this UUO is given. As a matter of fact, the interrupt will be taken
before any further instructions in your program are executed. The
bits in the accumulator are decoded as follows:
BIT 0 - INTSWW
If this bit is on, you will receive an interrupt when your job is
about to be swapped out.
BIT 1 - INTSWD
This bit enables an interrupt when your job is swapped back into
core. If you are enabled for interrupts for swap out also, you will
receive these two interrupts as a pair in the expected order every
time your job is swapped.
BIT 2 - INTSHW
If this bit is on, you will receive an interrupt when your job is
about to be shuffled.
BIT 3 - INTSHD
This will enable an interrupt when your job has been shuffled.
BIT 4 - INTTTY
This will cause an interrupt to be generated every time your
user-level program would be activated due to the teletype if it were
waiting for the teletype. This means if you set this bit on, you
will be interrupted every time either a character or a line has been
typed in depending on whether you are in character mode, line mode,
or whatever. As long as you do not ask for more than there is in the
teletype buffer, you may read from the teletype at interrupt-level.
II.D.16-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
BIT 5 - INTPTO
This bit allows interrupts every time the PTY job goes into a
wait state waiting for you to send it characters.
BIT 6 - INTMAIL
If this bit is on, you will be interrupted when someone sends you
a letter (see MAIL service, section II.D.17). You may read the
letter at interrupt-level.
BIT 8 - INTPTI
This allows interrupts whenever any job on a PTY you own sends a
character (or line) to you.
BIT 10 - INTCLK
This bit allows clock interrupts. See CLKINT for further
details.
BIT 19 - POV
This bit enables you to receive interrupts on push-down overflow.
BIT 22 - ILM
If this bit is on, you will receive interrupts on illegal memory
references, that is, references to memory outside of your core image.
BIT 23 - NXM
This allows interrupts when your program references non-existant
memory.
BIT 29 - INTFOV
If a floating overflow occurs while this bit is on, an interrupt
will be generated.
BIT 32 - INTOV
This bit enables an interrupt on arithmetic overflow.
The remaining bits are not used currently, except for bit 7. You
are not allowed to enable an interrupt by turning bit 7 on, because
it is just masked back out again by the monitor. This is because
this bit, called INTWAIT, is used by the monitor to make UWAIT work
right. This is the only reserved bit. As new interrupts are added,
they will use bits starting at bit 8 and going up. You may send
interrupts to yourself on bits in the right half and be fairly well
assured of winning for a while, at least.
II.D.16-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
INTORM CALLI 400026
MOVE AC,<bits to be ORed in>
CALL AC,[SIXBIT /INTORM/]
This does a logical OR with the bits in accumulator AC and the
bits that are already enabled for. In this manner, you may turn on
extra interrupts without affecting any previous interrupt enablings.
INTACM CALLI 400027
MOVE AC,<bits to be cleared>
CALL AC,[SIXBIT /INTACM/]
This causes the interrupts specified by the bits in accumulator
AC to be disabled. In this manner, you may disable certain
interrupts while preserving continuity for other previous interupt
enablings.
INTENS CALLI 400030
CALL AC,[SIXBIT /INTENS/]
This returns to you in accumulator AC the bits representing the
interrupts you have enabled yourself for. If you are not enabled for
any interrupts, a zero will be placed in accumulator AC.
INTIIP CALLI 400031
CALL AC,[SIXBIT /INTIIP/]
If you are not at interrupt-level, this UUO returns a zero in
accumulator AC. If you are at interrupt-level, you get the bit
representing the source of the interrupt that got you to
interrupt-level in the accumulator AC. This is just a copy of the
word that is placed in JOBCNI when your interrupt-level module is
started up.
II.D.16-5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
INTIRQ CALLI 400032
CALL AC,[SIXBIT /INTIRQ/]
This returns you in accumulator AC the bits representing the
interrupts you have currently pending. Usually this will be zero
unless you are at interrupt-level and currently processing one of a
number of essentially simultaneous interrupts. This will also be
non-zero if between the time an interrupt is requested and the time
it is serviced it is disabled. This can happen if your
interrupt-level module changes the interrupt enablings.
DISMIS CALLI 400024
CALL [SIXBIT /DISMIS/]
This UUO is illegal at user-level. At interrupt level, it causes
the interrupt to be dismissed and your user-level process to
continue. No further instructions are executed at interrupt-level
after this UUO until another interrupt occurs. This is how you get
out of interrupt-level.
INTGEN CALLI 400033
MOVE AC,<Bits to interrupt on>
CALL AC,[SIXBIT /INTGEN/]
This causes interrupts to be requested for you. The exact
interrupts to be generated are given by the bits in the accumulator
AC. You must be enabled for each of the interrupts you are
generating or else an error will occur. This will interrupt
immediately. Notice carefully that you may send yourself a (for
example) non-existant memory reference interrupt, even though a
non-existant memory reference has not occured. You can delude your
interrupt-level process entirely this way, so be careful with its
use.
II.D.16-6
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
USKIP CALLI 400041
CALL [SIXBIT /USKIP/]
<returns here if UWAIT will proceed>
This UUO is illegal at user-level. At interrupt-level, this UUO
tells you whether you may give a UWAIT UUO and proceed immediately or
not. Let me explain further. Interrupts may occur at roughly any
time your job is in core. If you just did a UUO, your PC will be in
EXEC mode because you will be in the monitor, processing the UUO. I
cannot, however, give you your actual PC, which is in EXEC mode,
because there is nothing you could do with it! You could not jump to
it, or cause the program to continue there because there is no
user-mode instruction that will jump into EXEC mode. For this
reason, if you receive an interrupt while in EXEC mode, I do not give
you your actual EXEC mode PC, but I give you the PC of the UUO that
is being processed. A UWAIT UUO will then plant an enabling for an
INTWAIT interrupt (bit 7) which will occur when your user-level job
goes back into user mode after processing that UUO. Since a UUO may
skip, the PC you received when the interrupt occurred may be off by
one, but the interrupt that causes you to continue from the UWAIT UUO
is guaranteed to give you the correct PC because the interrupt occurs
just before the monitor jumps back into your program at that PC.
Anyway, what this all means is that if your PC is in user mode, the
UWAIT will come back immediately and the PC you receive will be
identical to the one you got when the interrupt occurred. You can
detect this situation by noting that in this case, before you did the
UWAIT UUO, you could do a USKIP UUO and notice that it did not skip.
If the USKIP UUO does skip, this means that your PC word is not
necessarily correct and the UWAIT UUO will cause your interrupt-level
process to be suspended until the UUO in progress is completed.
Other interrupts may also occur in this time.
UWAIT CALLI 400034
CALL [SIXBIT /UWAIT/]
This UUO is not legal at user-level. At interrupt-level, this
UUO returns immediately if your user-level job was not in the middle
of doing a UUO at the time the interrupt occurs, or returns when the
UUO is completed. The PC word is again placed in JOBTPC, bit 7 will
be on in the word in JOBCNI, and the accumulators you have are not
the ones you had when you did the UWAIT UUO, but instead are the ones
that your user-level job had. This means you may return to your user
II.D.16-7
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
level job by doing a DEBREAK UUO next and jumping to the address
specified by the PC word in JOBTPC. The accumulators you have will
be the ones the user-level job had at the time the interrupt
originally occurred.
If you do a UWAIT UUO and do not return immediately, there is a
time during which other interrupts may occur and you may even do
another UWAIT UUO. If you do, your interrupt-level process will
continue immediately after the UWAIT UUO that was most recently done.
If you do a UWAIT UUO and then decide that you really don't want
to debreak after all, you may just give a DISMIS UUO as usual with no
ill effects.
It should also be noted that if you are in SLEEP (see SLEEP UUO)
when the UWAIT is given, your sleep is terminated, so the UWAIT does
not hang until your sleep time is up.
DEBREAK CALLI 400035
CALL [SIXBIT /DEBREAK/]
This UUO is illegal at user-level. At interrupt-level this UUO
causes your interrupt-level process to become your user-level process
starting at the instruction immediately after the DEBREAK UUO. Your
accumulators are the same before as after the UUO, and if you were in
IOT-USER mode before the UUO, you will continue to be after the UUO.
If you have done a UWAIT UUO previously, you can cause your
user-level process to continue. Otherwise, you may not be able to
continue your user-level process successfully.
It is legal to do a debreak without doing a UWAIT first. In this
case, you can not in general continue your user-level process
successfully because your PC and your accumulators may not be
correct.
IWAIT CALLI 400040
CALL [SIXBIT /IWAIT/]
This UUO causes your job to go into a wait state that is
terminated when an interrupt occurs.
II.D.16-8
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
IENBW CALLI 400045
MOVE AC,<interrupt bits>
CALL AC,[SIXBIT /IENBW/]
There are a number of interesting race conditions involved in the
interrupt system. This UUO solves one of them. Suppose your
interrupt level process actually does nothing, but you are using
interrupts to bring you out of a wait state. In this case, there is
a possibility that between the time you enable for interrupts and the
time you put yourself in a wait state, an interrupt may occur. This
will have the undesired effect of causing your job to wait forever
for an interrupt that has already gone by. This may be solved in two
or more ways. One way is to have your interrupt-level process do a
UWAIT and a DEBREAK instead of just doing nothing, another way is to
use this UUO which enables your interrupts and puts you into a wait
state in one single indivisible operation. This is exactly the same
as doing an INTENB followed by an IWAIT.
INTMSK UUO 720
INTMSK <processor>,ADR
ADR: <interrupts this processor may receive>
Each processor (PDP-6 or PDP-10) may receive interrupts. There
is a mask for each processor and each job that tells what interrupts
may be received on what processors. The main processor is the PDP-10
and is processor number 1. The PDP-6 is processor number 2. The
mask for processor 1 is normally all ones. The mask for processor 2
is normally 0.
Receiving interrupts on a processor other than the one which
generated the interrupt can be hazardous, for there is no information
transmitted as to which processor caused a given interrupt. When
your interrupt-level process is started up, accumulator 4 contains a
1 or a 2, signifying the processor that is running the process, not
the originator of the interrupt.
II.D.16-9
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
IMSKST UUO 721
IMSKST <processor>,ADR
ADR: <bits to be ORed into processor mask>
This UUO sets the specified bits in the appropriate processor's
interrupt mask.
IMSKCL UUO 722
IMSKCL <processor>,ADR
ADR: <bits to be ANDCAMed into processor mask>
This UUO clears the specified bits in the appropriate processor's
interrupt mask.
CLKINT UUO 717
CLKINT <processor>,<number of ticks>
One may enable one's job for clock interrupts. If this is done
using the INTENB, INTORM, IENBW, or INTJEN UUO, there is no
specification for how often you wish to receive the clock interrupt.
In this case, the default option of 1 tick (a tick is a 60th of a
second) is assumed. The CLKINT UUO is to allow the user to set the
number of ticks between clock interrupts to any number representable
in 18 bits. This does the function of an INTENB, followed by an
INTMSK, followed by the setting of the interval between interrupts to
the number in the effective address of the UUO.
INTUUO UUO 723
INTUUO <function>,ADR
This is the multi-purpose interrupt UUO. Its many functions (one
at present) are explained below:
II.D.16-10
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
INTJEN INTUUO 0,
INTJEN ADR
ADR: <interrupt bits to be ORed in>
<PC word to go to>
This UUO is to solve another interesting race condition. Suppose
you have done a UWAIT followed by a DEBREAK, fooled around in
user-level for a while, and now wish to enable your interrupts again
and return to the original user-level process. You presumably have
the PC word stored in a location somewhere. If you enable your
interrupts and then try to jump back to the original user-level
process, you may get interrupted between the INTENB (or whatever) and
the jump. The second interrupt may want to do the same thing and may
in the process overwrite your PC word with a new and different PC.
This UUO solves this race by setting the interrupt bits at ADR and
jumping to the PC in ADR+1 all in one indivisible operation, so that
if another interrupt occurs, the PC it gets will be the one specified
in ADR+1.
II.D.16-11
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.17 WHAT HAVE YOU . . .
EIOTM CALLI 400005
CALL [SIXBIT /EIOTM/]
This UUO causes you to go into IOT-USER mode. In this mode,
operation codes 700 and above are not UUOs, but instead are machine
IO instructions. The purpose of this mode is to allow the user to
get at devices which are not handled by the system, or are
special-purpose devices.
LIOTM CALLI 400006
CALL [SIXBIT /LIOTM/]
This UUO gets you out of IOT-USER mode and makes op codes 700 and
above into UUOs again.
CORE CALLI 11
CALL AC,[SIXBIT /CORE/]
<error return>
<successful return>
This UUO allows you to change your core size. The highest
location your program is allowed to reference is kept in your job
data area in JOBREL. If you want to change your core size, you put
the number you want JOBREL to be in an accumulator AC and give this
UUO. If you can be given this much core, the UUO takes the
successful return. If you may not have this much core, the UUO takes
the error return and puts the number of 1K blocks left in the
accumulator. If this UUO is called with 0 in AC, it always takes the
successful return and gives you the number of 1K blocks left.
WAIT CALLI 10
CALL <channel number>,[SIXBIT /WAIT/]
This causes your job to be suspended until all IO is completed.
II.D.17-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
Normally, the monitor will be doing IO to your buffered mode devices
while your program is running, which means that you can not count on
the data that is in buffers other than the one pointed to by your
buffer header to stay constant. After this UUO, the buffers will be
stable and no more IO will be done until you give another IO UUO.
EXIT CALLI 12
CALL [SIXBIT /EXIT/]
This UUO calls CLOSE on each of your IO channels and then returns
you to the monitor the way control-C does. The difference between
this and control-C is that with control-C, your IO channels are left
open and you may pick up by saying CONTINUE. With this UUO, it is as
if you had given a CLOSE UUO on each channel you had open and when
you EXIT this way, you may not continue by typing CONTINUE.
LOGIN CALLI 15
CALL AC,[SIXBIT /LOGIN/]
This is a privileged UUO, in that if anyone but the LOGIN program
executes it, an error message is given. The LOGIN program when it is
ready to establish your project-programmer name, puts a word in the
accumulator AC whose left half is the number -1 and whose right half
is the address where the project-programmer name is. The monitor
picks up the project-programmer name and stores it. The user is then
officially logged in and the LOGIN program exits.
LOGOUT CALLI 17
CALL [SIXBIT /LOGOUT/]
This is a priveleged UUO in that if anyone but the LOGOUT program
uses it, an illegal UUO error message is given. If you are the
LOGOUT program and you give this UUO, it clears your
project-programmer name and releases your job number, thereby erasing
any record the system has of your existance.
II.D.17-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
SLEEP CALLI 31
MOVE AC,<number of seconds>
CALL AC,[SIXBIT /SLEEP/]
This UUO causes your job to be stopped for the number of seconds
specified by the contents of accumulator AC at the time the UUO is
given. You may not sleep for more than 60 seconds. If you type
control-C while you are sleeping and then continue, it will be as if
the UUO were never given. You may not get started up exactly when
you would expect, because during your sleep, you may have gotten
swapped out or whatever. It takes a small but finite time for your
job to get brought in and rescheduled before your job is started up.
This UUO just makes the system ignore you completely for that number
of seconds, and then treat you as usual.
MAIL UUO 710
MAIL <function>,ADR
The purpose of this UUO is to allow 32 (decimal) word letters to
be passed between consenting jobs. The sending job identifies the
destination job by either the job number or the job name in sixbit in
ADR. If there are two jobs of the same name, the ambiguous addressee
error message will be given. If there is no job logged in under the
given job number, or if there is no job of the given name, the
addressee unknown error message will be given. I shall proceed to
explain all the various functions this UUO is capable of:
SEND MAIL 0,ADR
SEND ADR
<mail cannot be delivered>
<successful return>
ADR: <destination identification>
<address of 32 word letter>
This UUO sends 32 words of data to the job whose job number or
job name in sixbit is in ADR. the 32 words of data are assumed to be
the 32 words at the address specified in ADR+1. If the addressee
already has a letter that he hasn't read yet, this UUO will return
without skipping. This means the mail cannot be delivered because
II.D.17-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
his mailbox is full and he must read his letter before he may be sent
another. If the mail can be delivered, this UUO skips.
WRCV MAIL 1,ADR
WRCV ADR
ADR: <32 words where letter is to go>
This UUO takes the 32 word letter that is waiting for you and
puts it in the 32 words at the address specified by the effective
address of the UUO, denoted above by ADR. If there is no letter
waiting for you, your job is put into a wait state until someone
sends you a letter.
SRCV MAIL 2,ADR
SRCV ADR
<no letter for you>
<successful exit>
ADR: <32 words where letter is to go>
This UUO takes the 32 word letter that is waiting for you and
puts it in the 32 words at the address specified by the effective
address of the UUO, denoted above by ADR, and then skips. If there
is no letter waiting for you, this UUO does not skip and does not
deposit anything in ADR.
SKPME MAIL 3,
SKPME
<no letter for you>
<a letter is waiting>
You may use this UUO to see if there is a letter waiting for you.
If there is a letter, the UUO skips. Otherwise, the UUO does not
skip.
II.D.17-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
SKPHIM MAIL 4,ADR
SKPHIM ADR
<no letter for him>
<he has a letter waiting for him>
ADR: <identification of job whose mailbox you wish to test>
This UUO may be used to tell whether a given job has a letter
waiting for him. If the job whose identification is in ADR has a
letter waiting for him, the UUO will skip. Otherwise, the UUO will
not skip.
APRENB CALLI 16
MOVE AC,<condition code>
CALL AC,[SIXBIT /APRENB/]
This UUO enables your job to be interrupted on any of several
conditions specified by the bits in the accumulator AC. When one of
these conditions occurs, the PC at the time of the condition is
placed in JOBTPC in your job data area. The APR flags are placed in
JOBCNI in your job data area, and your program is started at the
address contained in JOBAPR in your job data area. You may get back
to your program by jumping to the address contained in JOBTPC if you
know what you are doing. The reason you have to know what you are
doing is that illegal memory reference traps may occur after certain
data has been altered, so that if you continue, you will not
necessarily get the desired result. For example, if the instruction
in question is, let us say, an AOJA that gets a trap when the jump is
attempted, you may not do this instruction over again, because it has
already incremented the accumulator once and you wouldn't want it to
increment the accumulator again.
Also, if you enable yourself for clock traps, you may get some
interesting results. First off, you only get the trap if your job is
running and not in any kind of wait state. This means you may lose
quite a few clock interrupts. Second, if you take a clock trap and
spend more than 16 milliseconds processing the trap, another trap
will take place and screw up JOBTPC! So, you must know what you are
doing. In any case, here is a list of the bits in accumulator AC and
their effects:
BIT 19
This enables interrupts for pushdown overflow.
II.D.17-5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
BIT 22
This enables an interrupt on an illegal memory reference.
BIT 23
This enables an interrupt on a non-existant memory reference. It
is impossible in the normal course of events for this to happen, so
it is sort of useless.
BIT 26
This enables you for clock interrupts. This will cause an
interrupt every 16 milliseconds (60 times a second to be exact) while
your program is running.
BIT 32
This enables you for arithmetic overflow interrupts.
SWAP CALLI 400004
MOVE AC,[XWD E,F]
CALL AC,[SIXBIT /SWAP/]
E: <device name in SIXBIT>
<file name in SIXBIT>
<file name extension in SIXBIT>
XWD <core size in 1K blocks>,<starting address>
<project-programmer name>
F: <device name in SIXBIT>
<file name in SIXBIT>
XWD <file name extension>,<mode bits>
XWD <core size in 1K blocks>,<starting adr increment>
<project-programmer name>
This UUO does what the system SAVE and RUN commands do. The left
half of the accumulator contains the address of the 5-word block that
says where your core image is to be saved. If the left half of the
accumulator is zero, no save will be done. The right half of the
accumulator contains the address of the 5-word block that says what
file you wish to run. If the right half of the accumulator is zero,
no run is done. If the accumulator is zero, nothing is done.
All of this needs further explaining. If you wish to save your
current core image on the disk in the format used by the SAVE and GET
commands, you may call this UUO and put in the left half of the
accumulator the address of a five-word table that specifies the
device name, the file name, the extension, the number of K of core
you wish to save the core image in, and the starting address you wish
the job to have, and the project-programmer name of the disk area you
II.D.17-6
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
wish to write your core image on. If the core size is zero, the
amount of core you currently have will be used. If the starting
address is zero, the current starting address of your job will be
used. If the project-programmer name is zero, your
project-programmer name will be used. In fact, the only things you
have to include are the device name, the file name, and the
extension.
This UUO will first do a RESET UUO to close all your IO channels,
then perform the save just as if you had typed the command yourself.
You may later get the core image back with a RUN or a GET command, or
by the RUN portion of another SWAP UUO.
If you want to run a program, you may use this UUO with the right
half of the accumulator AC containing the address of a 5-word block
which contains the device name where the core image you wish to run
exists, the file name of the core image, the file name extension, the
number of K of core you wish the job to run in, and the amount you
wish the starting address of the job to be changed by, and the
project-programmer name in sixbit. If the core size is zero, the
amount of core the core image was saved in will be used. If the
starting address increment is zero, the starting address in the core
image will be used. Note that the number contained in the right half
of jOBSA in the job data area of the core image you are calling in is
not altered, so that if you start up the job at some strange place,
then say control-C and then START, it will be started at its given
starting address, not at the strange place. The project-programmer
name may be zero, in which case, your project-programmer name will be
used. In the right half of F+2, the file name extension word, you
may specify special conditions. If bit 35 is on, the job will not be
started, but instead the message "JOB SETUP" will be given and
control will be returned to the monitor. If bit 36 is on, the right
half of F+3 will be taken to be the absolute starting address, rather
than the starting address increment.
Again, if E (the left half of the accumulator AC) is zero, no
save will be done. If F (the right half of the accumulator AC) is
zero, no run will be done. The save is done before the run, so if
you wanted to, you could save your own core image and get it back
again all in one UUO.
SETNAM CALLI 400002
MOVE AC,<name you want in SIXBIT>
CALL AC,[SIXBIT /SETNAM/]
The purpose of this UUO is to allow you so set the name of your
job. Normally, the job name is set from the file name when you do a
GET or a RUN command. The Loader uses this UUO to establish the job
name of programs it has just loaded. You may use it to change your
II.D.17-7
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
name to anything.
REASSI CALLI 21
MOVE AC,<job number>
MOVE AC+1,<device name in SIXBIT>
CALL AC,[SIXBIT /REASSI/]
This UUO does the same as the REASSIGN console command. To use
it, you put the job number you wish to reassign the device to in
accumulator AC, and you put the device name in SIXBIT that you wish
to reassign in accumulator AC+1 and give this UUO. If it returns
with AC set to zero, you job number you gave was not the number of a
logged in job. If accumulator AC+1 is set to zero, then the device
is not assigned to this job, or the device may not be reassigned at
this time.
RESET CALLI 0
CALL [SIXBIT /RESET/]
This UUO clears all your IO channels and resets JOBFF in your job
data area to the number in the left half of JOBSA. If you have any
files open, they are released. If you were writing a file, it goes
away. If you had a III display program running, it is cleared and
your page printer is reset to the normal values.
RUNMSK CALLI 400046
MOVE AC,<processor enable bits>
CALL AC,[SIXBIT /RUNMSK/]
This UUO will be used to set the number of the processor that is
allowed to run your job. It is currently not a wise idea in that the
PDP-6 is not capable of running jobs now. Bit 35 means P1 (the
PDP-10) can run this job. The defaule option is this bit on. Bit 34
means P2 (the PDP-6) can run this job. If both bits are on, the job
will go to the processor that is free at the time. If both bits are
off, the job will not be run. When the job is initialized, this is
set to 1, meaning P1 may run the job but P2 may not.
II.D.17-8
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
SLEVEL CALLI 400044
MOVE AC,[XWD <service level>,<job number>]
CALL AC,[SIXBIT /SLEVEL/]
This UUO may be used to find out what service level a job has,
and may be used `to decrease your service level. If the job number
is zero, your job number will be used. If the service level is
negative, your service level will be returned in the accumulator AC.
If an error occurs, like job number out of bounds, a zero will be
returned in the accumulator AC.
CALL UUO 040
CALL AC,[SIXBIT /<function>/]
This is a multi-purpose UUO. The exact function depends upon the
sixbit word that the effective address points to. For a complete
description of all the various functions that this UUO is capable of,
read the individual UUO writeups in this chapter.
CALLI UUO 047
CALLI AC,<function>
This is an alias for the CALL UUO. The difference is that
instead of the effective address pointing to a word in memory that
contains the function name in sixbit, the effective address itself is
the function number. For a list of the available function numbers
and what functions they correspond to, read the individual UUO
writeups in this chapter.
II.D.17-9
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.D.18 FURTHER EXAMPLES
In seeking examples of good coding, I encountered great
difficulty in that most short routines which would be good for an
example are imbedded in inextractable fashions inside much larger
programs. If anyone generates any simple routines which would be
good for examples, please bring them to my attention.
; Routine to convert a SIXBIT symbol into RADIX50
; Accumulators T,T1,T2,T3,SYM, and P must be defined elsewhere
; Enter with SIXBIT symbol to be converted in SYM
; Call with a PUSHJ P,C6250
; RADIX50 symbol returned in T
C6250:
setzm t
move t1,[point 6,t]
move t2,6
c62501: ildb t3,t1
imuli t,50
cail t3,'0'
caile t3,'9'
jrst c62502
subi t3,17
jrst c62503
c62502: cail t3,'A'
caile t3,'Z'
jrst [ jumpe t3,c62503
cain t3,'.'
jrst [ movei t3,45
jrst c62503]
cain t3,'$'
jrst [ movei t3,46
jrst c62503]
movei t3,47
jrst c62503]
subi t3,26
c62503: addi t,(t3)
sojg t2,62501
popj p,
II.D.18-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
; Routine to convert a RADIX50 symbol to SIXBIT notation
; Accumulators T,T1,T2,T3,SYM, and P must already be defined
; Put RADIX50 symbol in accumulator T
; Call with PUSHJ P,C5026
; Returns SIXBIT representation in SYM
; Uses at least 6 words of pushdown list P for temp. storage
C5026:
setzm sym
move t2,[point 6,sym]
c50261: idivi t,50
hrlm t1,(p)
skipe t
pushj p,c50261
hlrz t1,(p)
cail t1,1
caile t1,12
jrst c50262
addi t1,17
jrst c50263
c50262: cail t1,13
caile t1,44
jrst [ jumpe t1,c50263
cain t1,45
jrst [ movei t1,'.'
jrst c50263]
cain t1,46
jrst [ movei t1,'$'
jrst c50263]
movei t1,'%'
jrst c50263]
addi t1,26
c50263: idpb t1,t2
popj p,
II.D.18-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.E DEVICE-DEPENDENT PECULIARITIES
II.E.1 LINE PRINTER
There are several extra characters available on the line printer
that you do not normally get. There is no STOPGAP representation for
these characters and it is quite difficult to get them into text.
Since all 128 codes are already used up, you specify these extra
characters by preceding them with the character 177, which by itself
does not print. These are the characters:
ASCII CHARACTER
000 center dot
011 gamma
012 apple (small delta?)
013 integral sign
014 plus-minus
015 circle-plus
020 space 1/2 page down
021 space 1 line - write over page boundary
022 space 3 lines
023 space 1/3 page down
024 space 1/6 page down
177 \
This means that you can get a center dot by sending two
characters, a 177 followed by a 000. You can get a plus-minus sign
by sending a 177 followed by an 014, and so on.
The line printer does not really use the same character set as
the rest of the system. There are several differences. The user is
not generally aware of the differences, because the system converts
the characters to compatible code before sending them to the line
printer. If you initialize the line printer with the 100 bit (bit
29) on in the mode (IO status) bits, this inhibits the system
character conversion. In this mode, you get the following
characters:
CODE CHARACTER LINE PRINTER
030 _ ←
032 ~ ↑
100 @ '
134 \ }
136 ↑ circumflex
137 ← →
140 ` @
174 | \
176 } |
All this means is that if you are in mode 100 and send the ASCII
character 134 to the line printer, you will get a tilda instead of a
II.E.1-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
backslash. If you are in mode 100 and send the ASCII character 032
to the line printer, you will get an uparrow instead of a circumflex.
II.E.2 PAPER TAPE PUNCH
The reason the paper tape punch is complicated is first because
there are several different formats used on paper tape, depending on
what is to read the tape after it is punched, and because the CALCOMP
plotter is hooked in to the paper tape punch because we're too cheap
to build another separate interface. The system has several
different modes the punch operates in, depending on the mode number
and whether the 100 bit is on or not.
Since the operation of the paper tape punch is so highly mode
dependent, I shall describe the operation mode by mode:
MODE 0
In this mode, a delete (ASCII 177) is punched after every
carriage return, line feed, vertical or horizontal tab, and 30 blank
spaces are punched after every form feed. The eighth hole is punched
as an even parity bit.
MODE 10
In this mode, the rightmost eight bits (bits 28-35) of each word
are punched directly as the eight bits a line of paper tape has.
This is the mode the CALCOMP plotter is generally run in, because the
plotter needs to receive characters without any editing by the
system. This mode transmits the characters exactly as they appear in
your buffer.
MODE 13
This is binary mode. In this mode, words are taken from the
buffer and punched 6 bits at a time on the paper tape. The eighth
hole is always punched, the seventh hole is never punched.
MODE 14
This is the same as mode 13, except that after each buffer is
punched, the 12-bit folded checksum of that buffer is punched. On
reading the tape, this number is checked to insure accuracy of
reading.
MODE 100
This mode is like mode 0 except that the eighth hole is never
punched and nothing special is done after any character. No extra
deletes are punched.
MODE 113
This is the same as mode 13 except that the eighth hole is never
punched.
II.E.2-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
MODE 114
This is identical to mode 113.
II.E.3 DECTAPES
Since most of the information about dectapes has been given in
sections II.D.10 and II.D.11, I shall just describe the formats of
data on the tapes in old and new formats.
First off, there are two formats used. There is old format,
sometimes called PDP-6 format. There is also new format, sometimes
called PDP-10 format. Old format is a non-reclaiming scheme, whereby
if you delete a file, you do not get the space back. If this sounds
like a losing scheme to you, it is only because it is. But, for
historical reasons, we are stuck with it until all tapes recorded in
that manner are stamped out. Anyway, this is how old format works:
The first five words of an old format directory are not file
information. the second to the fifth words are not used at all. The
first word has in the left half the number of the first unused block
on the tape. Every time another block is written on the tape, this
number is incremented by one. This is the number you get when you do
a UGETF UUO. The right half of the first word must be the number 5.
After the first five words, you have 4 words per file entry, and a
zero entry terminates the list. The 4 words are exactly what you get
when you do a LOOKUP. The first word is the file name, the left half
of the second word is the file name extension, the right half of the
second word is the block number of the first block of the file, the
third word is the date of creation, and the last word is whatever was
in the fourth word of the ENTER block when the file was created.
If this file was written in buffered mode, then each block has
177 words of data. The first word of each block contains in the left
half the number of the next block in the file, or zero if this is the
last block, and the count of the number of data words (177 maximum)
in this block in the right half.
If the file was written in dump mode, there are no block pointers
or word counts in each block. There are 200 words of data in each
block, and the file is written on consecutive blocks always.
On old format dectapes, the directory is located on block 1.
So much for old format. It isn't really very interesting. The
format of the directory of new format tapes is somewhat more complex.
First off, the directory of new format tapes is found on block 100
(decimal!). The first 83 (decimal) words of the tape are 5-bit bytes
that contain, one byte for each block on the tape, the number of the
file that block belongs to, or zero if the block is unclaimed. The
way you find the number of the first block of a file is you start
looking at these 5-bit bytes starting at block 99 (decimal) and
working down toward 1 until you find the first block claimed by that
file number. That is the first block of the file.
II.E.3-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
In words 83 to 104 (decimal) you have the file names of the 22
files a dectape is capable of holding. In words 105 to 126 (decimal)
you have the extension in bits 0 to 17, the number of 1K blocks this
file occupies in bits 18-23 (only for dump mode files), and the date
of creation in bits 24-35.
When I say the file names occupy words 83 to 104, this is
counting the first word of the directory as word 0 and the last word
as word 127.
In all modes on new format dectapes 177 words of data are stored
in each block and the first word of each block contains the block
number of the next block in the left half and the word count of this
block in the right half.
In new format dectapes, blocks 0, 1, and 2 are not used for
files. A special read-in mode loader may be placed there for
installations with TU55 dectape drives, which Stanford does not have.
II.E.4 DISK
The first feature I shall discuss is the long form of lookup
tables. If you INIT the disk with the 400 bit (bit 27) on in your IO
status word, you get the long form scheme. In this mode, LOOKUPs,
ENTERs, and RENAMEs all use a 6-word block rather than a 4-word
block. The fifth word is the date the file was last accessed and the
sixth word is the date the file was last dumped by DAEMON. In this
mode also, an ENTER will set the creation date of the file to
whatever is in the 6-word block. When DAEMON dumps a file, it sets
the last word of the 6-word block to the date of dumping. When a
file is dumped incrementally, that date is changed to the date of the
incremental dump, and the sign bit (bit 0) is set to 1 to signify
that this was an incremental dump. When a file is created by a
program not using the 400 mode, like STOPGAP or anyone but DAEMON,
the 2 extra words are set to zero. In this way, DAEMON knows that
this file is new and should be dumped.
The other interesting feature of the disk service is the fresh
new use for the MTAPE UUO. An MTAPE UUO to the disk is an absolute
address read or write and is used by the disk auditor. The UUO is
also a way to get your USET pointer. Doing an MTAPE <channel
number>,ADR will, if the contents of ADR are not -1, place your USET
pointer in ADR. If the contents of ADR are -1, then absolute read
(or write) is signified. In this scheme, ADR+1 contains an IOWD
which specifies the word count and the starting address where data is
to be transferred to (from). ADR+2 must be zero, because ADR+1 to
ADR+2 form a dump mode command list. ADR+3 contains the logical
address on the disk you wish to reference, or zero if you wish to do
an absolute read. ADR+4 contains the absolute address on the disk
you wish to reference, or zero if you wish to do a logical read.
ADR+5 contains the mode, which should be 6 for read and 106 (octal)
for write.
II.E.4-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
Note carefully that any error in these specifications, expecially
in the logical or absolute record number, will kill the system! This
is a scheme for experts only!
This table will summarize the two usages of the MTApE UUO with
the disk:
MTAPE <channel number>,ADR
ADR: <if not -1, set to USET pointer>
MTAPE <channel number>,ADR
ADR: -1
IOWD <word count>,<address of first word>
0
<logical address if relative read>
<absolute address if absolute read>
<6 for read, 106 for write>
Anyone may get his USET pointer, and anyone may read any place on
the disk, but only 1,2 may write on the disk using this UUO.
For this UUO to be of any help, one must know the format of the
disk. I shall describe that next.
Logical block 1 is the master file directory, or MFD. This is a
file that contains as files all the users' file directories, or UFDs.
Each UFD contains a list of the files that that user owns. Each UFD
(the MFD is a UFD too!) is a list of 4-word blocks. Each block is
either zero, garbage, or a file name. If it is a file name, the
first three words are the words you get from a LOOKUP, that is file
name, file extension, and a bunch of dates. The last word of the
4-word block is the logical block number of the first block of the
file. A UFD is a file just like any other file. The name of the UFD
is the project-programmer name of the owner of the files it contains,
and the extension is .UFD. The MFD is the UFD for 1,1. The UFD
contains some number of file names and there is garbage after the
last file name. You can tell how long the reasonable part of the UFD
is by looking at the word count when you look it up. The word after
the last word specified by the word count is the beginning of the
garbage.
When you read the first block of the file with an absolute mode
read, you must be prepared for what you get. A block is 1024 (2000
octal) words long with a 32 (40 octal) word retrieval header in front
of it, so the total length of the block is 1056 words long. In
normal reading and writing, the user does transfers to the data
portion of the block. Only the disk service itself, and the absolute
mode read and write can access the retrieval header. The words in
the retrieval header are as follows:
II.E.4-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
WORD 0 - DDNAM
This is the file name in sixbit.
WORD 1 - DDEXT
File name extension.
WORD 2 - DDPRO
This is like the corresponding word in the LOOKUP block.
Protection, mode, and date information is kept here.
WORD 3 - DDPPN
This contains the project-programmer name of the owner of the
file.
WORD 4 - DDLOC
This is the logical block number of the first block of the file.
WORD 5 - DDLNG
This contains the negative of the number of words in the file.
WORD 6 - DREFTM
This would contain the date and time that the file was last
referenced, if it were updated.
WORD 7 - DDMPTM
This is the date the file was last dumped. It is updated only by
DAEMON.
WORD 10 - DGRP1R
This is the logical block number of the first block of this
group. A group is 32 1K blocks. If this is the first block of a
group, however, this will not be the block number of this block, but
instead will be simply a 1.
WORD 11 - DNXTGP
This is the logical block number of the first block of the next
group in the file. If this file is less than 32 1024 word blocks
long, then this word will be zero.
WORD 12 - DSATID
This word contains the SAT table identification number. This
number is changed every time the disk is wiped and refreshed.
WORDS 20-37 - DPTR
This is a list, two numbers per word, of the 1K blocks that
belong to this group of this file. The first block number is in the
left half of the first word.
II.E.4-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
Each 1K block in the file has this information in the header.
You see that this information is quite redundant, in that every
retrieval header of every block in a group contains exactly the same
information.
There is a block, logical block 0, that is called the sector
allocation table, or SAT. This contains, one bit per block, a record
of which blocks are claimed and which are not. If a block belongs to
some file, there is a 1 in the corresponding position in the SAT.
Bit 35 of the first word of the SAT represents logical block 1, bit
34 represents logical block 2, bit 35 of the second word represents
logical block 37, and so on. There is at the end of the SAT a list
of the bands on the disk which have been discarded due to data errors
also.
II.E.5 TV CAMERAS
The television camera may be INITed or OPENed just like any other
device. It operates only in dump mode input. It differs from all
other devices in that on the INPUT UUO it does not take a standard
dump mode command list. The address of the UUO must be the address
of a 4-word block that contains the following:
INPUT <channel number>,ADR
ADR: XWD -<word count>,<address of first word>
<TV camera CONO word>
<TV camera DATAO word>
<IOP bits upon completion>
To elaborate, the word at ADR should contain the negative of the
number of words you wish to receive in the left half, and the address
of the first word of data to be transferred in the right half. This
is not standard IOWD form. ADR+1 must contain the word that the TV
camera hardware takes directly. Its bits have the following
meanings:
BITS 18-20
This is the bottom converter clip level, referred to in the
literature as BCLIP. A sample is a 4-bit number which represents the
intensity at that point. This means there are 16 levels of
intensity. If you set the bottom clip level to 0, then nothing but
the brightest points will produce anything but a zero sample. If you
set the bottom clip level to 7, then all points will produce a
non-zero sample.
BITS 21-23
This is the top clip level, known as TCLIP. If this is set to 0,
II.E.5-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
only the brightest points possible will register a sample value of
17. If this is set to 7, almost all samples will be 17.
The TV actually puts out an analog signal from 0 to 1 volt. The
clip level numbers correspond to the following voltage levels:
VALUE BCLIP TCLIP
0 7/8 1.0
1 3/4 7/8
2 5/8 3/4
3 1/2 5/8
4 3/8 1/2
5 1/4 3/8
6 1/8 1/4
7 0 1/8
This means that if you set BCLIP to 4 and TCLIP to 3, your
sixteen levels of contrast will all lie between 3/8ths of a volt and
5/8 of a volt. When the camera is completly dark, it puts out close
to 0 volts. When it is saturated, it puts out close to a volt. Your
clip levels give you the ability to control the exposure setting from
the program.
BITS 24-26
This is the camera number. There are eight possible camera
numbers, but only three of them are wired in permanently. The cart
camera is number 0, and the hand-eye camera by the electric arm is
number 1. The third one is the camera in the hydraulic arm room,
which is usually disconnected.
BITS 27-29
This is the vertical resolution times two plus two. If you set
it to zero, which is normal, you get every other line. If you set it
to one, you get every fourth line, and so on.
BITS 30-35
When the camera hardware came into existance, this was supposed
to be the horizontal resolution, or the number of X-positions over
which the signal is averaged. It turns out in practice that this
almost has to be set to 2. If set to 0, you don't get anything at
all.
OK, those are the bits for the CONO word in ADR+1, now for the
DATAO word in ADR+2:
BITS 0-8
This is your Y-coordinate displacement, 0 for the top of the
screen, 400 (octal) for the bottom of the screen. In practice, the
usable range is 26 to 373 (octal). This is the coordinate of the top
of the picture you will receive.
II.E.5-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
When a transfer is in progress, the Y coordinate is not
incremented by 1 each line, but is instead incremented by 2. This
means that if you give a starting Y coordinate of 0, you will get
lines 0, 2, 4, 6, and so on. You would not get the odd-numbered
lines. To get the entire picture, you would have to read a frame
with the starting Y coordinate set to 0, and then read another frame
with the starting Y coordinate set to 1.
BITS 9-17
This is the X-coordinate displacement, 0 for the left-hand side
of the picture, 515 for the right-hand side. In practice, the usable
range is from 6 to 515 (all octal).
BITS 18-26
This is the width of the picture in number of words. If this is
zero, you will get no picture at all. If it is one, you will get a
picture 9 samples (9 samples to a word) wide. The range on this is
from 0 to 44, for the entire screen, but the useful range is from 1
to 44.
If you get all these specifications right and the UUO returns to
you, then you probably have a picture in core, 9 samples to a word, 4
bits to a sample. The first sample is from the upper-left-hand
corner of the picture you specified by its X and Y displacement, its
horizontal width, and its word count. The next sample will be the
one adjacent to the previous and to the right, unless it is the end
of the line, and then it is the first (leftmost) one on the next
line.
The next thing you need to know is what the bits in ADR+3 mean.
This is the word in the IOP (type 167 data channel) control register
when the transfer is done. The bits are as follows:
BIT 20
This means a parity error has occurred. Since on input (which is
all the TV camera is capable of!) it is quite impossible to get a
parity error, this bit really means the universe is about to die and
you should tell the experts immediately.
BIT 30
This is the DATA MISSED flag and means a word (9 samples) was
missed by the memory and the transfer was terminated. This means you
ought to do the transfer over again until this bit comes back 0, or
else you can not be sure you have the entire picture.
BIT 31
This means the camera references a non-existant memory location.
This is not supposed to happen and you should call an expert if it
does!
II.E.5-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
BIT 32
This is the job done bit. If a transfer has been completed
successfully, this bit and possibly one of the above error bits will
be on. If this bit is not on, that means the camera is hung and is
not responding. This happens if the camera power is not on, or if
your specifications to the camera were incorrect in some strange way.
This complets the description of the TV camera. There already
exist working routines to read the camera and I strongly suggest you
use them rather than attempting to write your own.
II.E.6 AD-DA CONVERTER
The AD-DA converter (hereafter referred to as the AD) is another
one of those devices that doesn't take a standard dump mode command
list. Instead, it takes a 5-word block, the first of which is a
single IOWD that describes the command. The second word is the right
half of a CONO to the 136 that belongs to the AD. The third word is
the right half of a CONO to the AD itself. After the transfer, the
user will get back a CONI from the 136 in the fourth word and a CONI
from the AD in the fifth word. You must fend for yourself, for the
system does no error checking on those bits.
Please note that the only thing the DA converter operates is the
4-channel sound output system. There are other DA converters on the
machine, but they are not accessable through the monitor.
Now I shall describe the various bits you have to know about to
use this device:
WORD 2
This is the address part of a CONO 204, to the 136. This number
(unless you know about the 136 in detail already) should be 4250 for
input and 3650 for output.
WORD 3
This is the address part of a CONO 424, to the AD itself. These
are the bits and what they mean:
BITS 18-23
This is the AD multiplex channel number. If auto-indexing is
used, this is the beginning channel number. You can find a list of
the channel numbers and what devices they correspond to by looking at
SAILON number 21, addendum number 1.1, entitled "A/D CONVERTER
MULTIPLEXER PATCH PANEL" by Edward Panofsky.
The channel number is not pertinant for output, because the
multiplexor is not active on output.
BIT 24
Reset bit. Set this to 1 on output, set it to 0 for input.
II.E.6-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
BIT 25
A 1 in this position specifies auto-indexing. This means that
when a sample has been transferred, the multiplex channel number (see
bits 18-23 above) will be incremented by one before the next sample
is transmitted.
BIT 26
Stereo request. This is for output generally, but it could be
used for input. This causes the low-order bit of the channel number
to be complemented after each sample. This means that if you start
out with either channel 16 or 17, it will alternate between them. If
you set both this bit and bit 25, a logical conflict exists and
nothing will happen.
This is not true on output, because this bit and bit 25 are used
to specify the number of channels of sound output. If bit 25 is
zero, you may specify one channel by setting bit 26 to zero and two
channels by setting bit 26 to one. This means that samples are sent
alternately to output channels 1 and 2. If bit 25 is a one and bit
26 is a one, you get four channel output. This means that the first
sample is sent to channel 1, the next to channel 2, the next to
channel 3, the next to channel 4, the next to channel 1 again, and so
on. If bit 25 is a one and bit 26 is a zero, nothing happens.
BITS 30-32
This selects the clock speed. They are as follows:
SPEED 0
This means maximum speed. For 12 bit samples, this means 35
microseconds per sample.
SPEED 1
This means 20KC.
SPEED 2
25KC.
SPEED 3
10KC.
SPEED 4
50KC.
SPEED 5
100KC.
Of all the bits you get back, the only one that is really
important is the 136 data missed bit, which is bit 23, the 10000 bit.
If this comes on, that means your transfer lost a sample somewhere
and you should do the transfer again.
II.E.6-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
This is a sample input block to transfer 100 words to an address
called FOO from channel 10:
IOWD 100,FOO
4250
100010
0
0
This transfer has the clock rate set to 20KC also. A similar
output transfer would be done with this block:
IOWD 100,FOO
3650
104010
0
0
OK. This one has clock rate of 20KC also.
II.E.7 MAGNETIC TAPES
You already know about the special magnetic tape UUO (MTAPE), so
I will just describe some other things. First, there are special
bits in the IO status word which tell if the tape is at the beginning
of the reel, at the end of the reel, and what density the tape is.
These are the bits:
BIT 24 - IOBOT
This is the 4000 bit and is turned on if the tape is at the load
point and turned off when it is moved.
BIT 25 - IOTEND
The 2000 bit says that the end of tape marker has been seen. The
system will still let you do transfers even though there is no more
tape, so you will have to check this bit yourself. Since this bit
may come on at slightly different times depending on tape timing, you
cannot guarantee that the last record on the tape can be read
properly.
BIT 26 - IOPAR
If this bit is on, any tape being written will have even parity,
which is non-standard.
BITS 27 and 28
This specifies the tape density. Zero and 2 mean 556 bits per
inch, 1 means 200 bits per inch, and 3 means 800 bits per inch. At
Stanford, you should do all your transfers at 556 bits per inch,
because at 800 bpi, the data is so dense that you often get data
II.E.7-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
errors, and at 200 bpi, the field is so sparse that the data often
can't be read.
BIT 29 - IONRCK
The 100 bit in the status word means no re-reading is to be done.
Re-reading is usually done on both output and input when an error is
detected. After 10 tries, the system gives up and sets an error bit.
II.E.8 USER DISK PACK
You may INIT or OPEN a device whose name is UDP, if the system is
not swapping on the 2314. You must assign it by console command
first. You may then do dump mode input and output on it by giving a
dump mode IOWD followed by a block number 0 to 3999. Each block has
1312 words. To summarize, after you INIT the device, you may write
on it with the following instruction:
OUTPUT <channel>,ADR
ADR: IOWD <number of words>,<data address>
<block number 0-3999>
II.E.8-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
II.F ALPHABETICAL INDEX
accumulator II.A
accumulator field II.A
address II.A
address field II.A
ADVANCE command I.B.11
advance file II.D.7
advance record II.D.7
APRENB II.D.17
ASCID II.C.5
ascid representation II.C.5
ASCII II.C.5
ascii line mode II.C.1
ascii mode II.C.1
ascii representation II.C.5
ASCIZ II.C.5
asciz representation II.C.5
ASSIGN command I.B.8.c
ATTACH command I.B.9
ATTSEG UUO II.D.15
BACKSPACE command I.B.11
backspace file II.D.7
backspace record II.D.7
binary mode II.C.1
blank tape II.D.7
block number II.D.11
buffer II.C.3
buffer header II.C.3
buffer ring II.C.3
buffered mode II.C.1, II.C.3
BUFLEN II.D.13
bulk memory II.A
CALL II.D.17
CALLI II.D.17
CCONTINUE command I.B.6
channel number II.D.1
checksum I.B.2
circumflex II.D.4
clock interrupts II.D.17
CLKINT II.D.16
CLOSE II.D.5
command list II.C.2, II.D.4
COMPILE command I.B.4.a
CONFIG II.D.13
console teletype II.D.6
CONTINUE command I.B.6
control-Z II.D.4
II.F-1
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
COPY command I.B.3
CORE command I.B.8
CORE UUO II.D.17
core memory II.A
COREX command I.B.7
CORE2 UUO II.D.15
CORMAX II.D.13
CREATE command I.B.3
CREF command I.B.4.f.2
CSTART command I.B.6
CTLV II.D.6
data area II.C.4
data modes II.C.1
DATE II.D.13
date format II.D.13
DAYTIME command I.B.7
DDT command I.B.6
DEASSIGN command I.B.8
DEBREAK II.D.16
DEBUG command I.B.4.b
DELETE command I.B.3
DETACH command I.B.9
DETSEG UUO II.D.15
DEVCHR II.D.13
DEVEXT II.D.13
DEVFIL II.D.13
device characteristics II.D.13
device data block II.D.13
device names I.B.8.c
DEVIOS II.D.13
DEVLOG II.D.13
DEVLST II.D.13
DEVMOD II.D.13
DEVNAM II.D.13
DEVPPN II.D.13
DEVSER II.D.13
DIRECTORY command I.B.3
disk bands II.D.9
DISMIS II.D.16
display program II.D.8
DPYCLR II.D.8
DPYPOS II.D.8
DPYSIZ II.D.8
DUMP command I.B.11
dump mode II.C.1
dump mode command list II.C.2
dump record mode II.C.1
duplexing II.D.6
EDIT command I.B.3
II.F-2
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
effective address II.A
EIOTM II.D.17
end-of-file mark II.D.7
ENTER II.D.3
EOT command I.B.11
error code II.D.3
error messages I.E.3
EXECUTE command I.B.4.d
EXIT II.D.17
fast band service II.D.9
fast registers II.A
FBREAD II.D.9
FBWRT II.D.9
file protection II.D.3
file protection key II.D.3
FINISH command I.B.8.e
free block II.D.11
GET command I.B.5
GETLIN II.D.6
GETPPN II.D.13
GETSTS II.D.12
glass, piece thereof II.D.8
glitch II.D.8
HELP command I.B.7
high segment II.D.15
IDUMP command I.B.11
IENBW II.D.16
illegal memory reference trap II.D.17
image binary mode II.C.1
image mode II.C.1
IMSKCL II.D.16
IMSKST II.D.16
IN II.D.4
INBUF II.D.2
INCHRS II.D.6
INCHRW II.D.6
INCHSL II.D.6
INCHWL II.D.6
index II.A
index field II.A
index register II.A
indirect address II.A
indirect bit II.A
INPUT II.D.4
input character and skip II.D.6, see INCHRS, PTRD1S
input character and wait II.D.6, see INCHRW, PTRD1W
input line and skip II.D.6, see INCHSL
input line and wait II.D.6, see INCHWL
input string II.D.6, see PTRDS
II.F-3
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
INSKIP II.D.6
instruction field II.A
instruction format II.A
INIT II.D.1
INTACM II.D.16
INTENB II.D.16
INTENS II.D.16
INTGEN II.D.16
INTIIP II.D.16
INTIRQ II.D.16
INTJEN II.D.16
INTMSK II.D.16
INTORM II.D.16
INTUUO II.D.16
INWAIT II.D.6
IO status bits II.C.1, II.D.10
IOACT II.C.1
IOBKTL II.C.1
IODEND II.C.1
IODERR II.C.1
IODTER II.C.1
IOIMPM II.C.1
IOT-USER mode II.D.17
IOWC II.C.1
IOWD II.C.1
IWAIT CALL II.D.16
JBTADR II.D.13
JBTLIN II.D.13
JBTSTS II.D.13
JBTSWP II.D.13
JOB II.D.13
job data area II.C.4
job name II.D.17
job status word II.D.13
JOBAC II.C.4
JOBAPR II.C.4
JOBCHN II.C.4
JOBCNI II.C.4
JOBCOR II.C.4
JOBDA II.C.4
JOBDAC II.C.4
JOBDDT II.C.4
JOBENB II.C.4
JOBEXM II.C.4
JOBFF II.C.4
JOBFDV II.C.4
JOBHCU II.C.4
JOBJDA II.C.4
JOBNAM II.D.13
II.F-4
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
JOBOPC II.C.4
JOBPC II.C.4
JOBPDL II.C.4
JOBPD1 II.C.4
JOBPFI II.C.4
JOBPRT II.C.4
JOBQUE II.D.13
JOBREL II.C.4
JOBREN II.C.4
JOBSA II.C.4
JOBSAV II.C.4
JOBSYM II.C.4
JOBS41 II.C.4
JOBTPC II.C.4
JOBUSY II.C.4
JOBUUO II.C.4
JOB41 II.C.4
JSR (III display instruction) II.D.8
KJOB command I.B.2
legal device names I.B.8.c
letter II.D.17
Librascope UUOs II.D.9
line characteristics II.D.6, see GETLIN, PTGETL
line number II.D.6
LINKUP UUO II.D.15
LIOTM II.D.17
LIST command I.B.3
LOAD command I.B.4.e
LOGIN command I.B.2
locked into core II.D.14
logical device names I.B.8.b
logical end of tape II.D.7
LOGIN II.D.17
LOGOUT II.D.17
LOOKUP II.D.3
MAIL II.D.17
mailbox II.D.17
marked for deletion II.D.3
mode bits II.C.1, II.D.10
monitor mode II.D.6
MSTIME II.D.13
MTAPE II.D.7
NAMEIN II.D.13
negative-swapped word count II.D.3
non-existant memory interrupt II.D.17
nonstandard buffer sizes II.D.2
op code II.A
operation code II.A
OPTION.TXT I.B.2
II.F-5
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
OUT II.D.4
OUTBUF II.D.2
OUTCHR II.D.6
OUTPUT II.D.4
output character II.D.6, see OUTCHR
output character and skip II.D.6, see PTWR1S
output character and wait II.D.6, see PTWR1W
output string II.D.6, see OUTSTR, PTWRS7, PTWRS9
OUTSTR II.D.6
page printer II.D.8
parallel process II.D.14
PEEK II.D.13
PGACT II.D.8
PGCLR II.D.8
PGIOT UUO II.D.8
PGSEL UUO II.D.8
piece of glass II.D.8
piece of paper II.D.8
PJOB command I.B.7
PJOB UUO II.D.13
physical device names I.B.8.c
PNAME II.D.13
POINTS UUO II.D.15
PPACT UUO II.D.8
PPIOT II.D.8
PPPN command I.B.7
PPREL II.D.8
PPSEL II.D.8
PRJPRG II.D.13
protection II.D.3
protection key II.D.3
protection protection II.D.3
protection violation II.D.3
pseudo-teletypes II.D.6
PTGETL II.D.6
PTSETL II.D.6
PTIFRE II.D.6
PTOCNT II.D.6
PTRD1S II.D.6
PTRD1W II.D.6
PTRDS II.D.6
PTWR1S II.D.6
PTWR1W II.D.6
PTWRS7 II.D.6
PTWRS9 II.D.6
PTYGET II.D.6
PTYREL II.D.6
PTYUUO II.D.6
pushdown overflow interrupts II.D.17
II.F-6
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
QNAMS II.D.13
R command I.B.5
RADIX 50 II.C.5
radix 50 representation II.C.5
read protection II.D.3
REASSIGN command I.B.8
REASSIGN UUO II.D.17
REENTER command I.B.6
regular service II.D.14
RELEAS II.D.5
REMAP II.D.15
RENAME command I.B.3
RENAME UUO II.D.3
RESET II.D.17
RESOURCES command I.B.7
RESTORE command I.B.11
rewind II.D.7
REWIND command I.B.11
RUN command I.B.5
RUNMSK II.D.17
RUNTIM II.D.13
run time II.D.13
SAVE (III display instruction) II.D.8
SAVE command I.B.5
sector number II.D.9
segment II.D.15
SEGNAM II.D.15
SEGNUM II.D.15
SEGSIZ II.D.15
SEND UUO II.D.17
SEND command I.B.3
SETLIN II.D.6
SETNAM II.D.17
SETNM2 II.D.15
SETPRO II.D.15
SETSTS II.D.12
SETUWP II.D.15
SIXBIT II.C.5
sixbit representation II.C.5
SKPHIM II.D.17
SKPME II.D.17
SLEEP II.D.17
SLEVEL command I.B.8
SLEVEL UUO II.D.17
spacewar buttons II.D.14
spacewar mode II.D.14
SPCWAR CALL II.D.14
SPCWAR UUO II.D.14
SPCWGO II.D.14
II.F-7
SAILON NUMBER 55.2 MONITOR MANUAL - CHAPTER II
special activation mode II.D.6
SP2GO II.D.13
SPWGO II.D.13
SRCV II.D.17
START command I.B.6
STATO II.D.12
status bits II.C.1, II.D.10
STATZ II.D.12
SWAP II.D.17
SWITCH II.D.13
switch register II.D.13
SYSTAT command I.B.7
system date format II.D.13
TALK command I.B.9
TIMER II.D.13
time of day II.D.13
TLIST command I.B.11
TPMON II.D.6
TRANSFER I.B.3
TRY command I.B.4.c
TTIME II.D.13
TTYIOS II.D.6
TTYUUO II.D.6
TYPE command I.B.3
UDP II.E.8
UINBF II.D.2
UFBCLR II.D.9
UFBGET II.D.9
UFBGIV II.D.9
UOUTBF II.D.2
UPGIOT II.D.8
UPGMVE II.D.8
UPGMVM II.D.8
UPTIME II.D.13
UGETF II.D.11
User disk pack II.E.8
USETI II.D.11
USETO II.D.11
USKIP II.D.16
UTPCLR II.D.10
UUO (definition of) II.B
UWAIT II.D.16
WAIT II.D.17
word II.A
word mode II.D.6
WRCV II.D.17
write protection II.D.3
ZERO command I.B.3
II.F-8